CustisWiki - Вклад участника [ru]

Continuous Integration

2009-08-20T11:59:28Z

Andrew: /* Юмор */

= Введение =
«Continuous Integration» — это лекарство от страха. Помогает при программировании.
Dr. Zoidberg ©

Согласно [http://en.wikipedia.org/wiki/Continuous_Integration Wikipedia] термин Continuous Integration введен Мартином Фаулером (Martin Fowler) и Кентом Беком (Kent Beck). Данный термин был придуман ими для обозначения практики частой сборки (интеграции) проекта. Максимально частая сборка является логичным продолжением цепочки
итерационные сборки -> ночные сборки -> непрерывная сборка

В настоящее время Continuous Integration (непрерывная интеграция) одна из практик применяемых в семействе гибких (Agile) методологий. В подобных методологиях она удачно сочитается с другими практиками, такими как модульное(unit) тестирование, рефакторинг, стандарт кодирования. Но даже без них можно получить пользу от непрерывной интеграции.

= Основные принципы =

== Каждое изменение должно интегрироваться ==

Слово continuous в термине [[Continuous Integration]] означает «непрерывный/непрекращающийся». Это означает, что в идеале сборка вашего проекта должна идти буквально все время. Каждое изменение в системе контроля версий (например [[CVS]]) должно интегрироваться без пропусков или задержек. Организация ночных сборок — это хорошая практика, но это не continuous integration. Ведь результаты такой ночной сборки будут доступны лишь на следующий день, когда их актуальность для разработчиков уже значительно снижена. На практике довольно часто реализуют оба процесса и непрерывную интеграция и ночные сборки — более редкую интеграцию.
В очень крупных проектах это требование иногда невозможно соблюсти, но интеграция каждые сутки это предел за который не стоит уходить.
Принцип непрерывной интеграции не выполним без другого условия — «Сборка должна идти быстро».

== Быстрая сборка ==

«Сборка должна идти быстро» — точнее не более 10 минут. Если после одного небольшого коммита ваш интеграционный сервер будет уходить в 2-х часовое пыхтение на сборку, тестирование и разворачивание от этого будет мало пользы. Разработчики будут уже далеко, над решение других проблем, им будет сложно вернуться и понять причины сбоя, если таковой был. Ведь суть непрерывной интеграции в получении быстрого feedback. Вдобавок, поздний ответ с сервера может отвлечь их от другого дела.

В случае если все этапы процесса никак не удается втиснуть в приемлемые временные рамки можно разделить его на несколько частей. При каждом коммите производить лишь саму сборку и минимальный набор тестов (smoke tests), чтобы уменьшить время. А по ночам проводить полный цикл интеграции, результаты которого команда будет анализировать с утра. Но это скорее вынужденная мера, а не пример для подражания.

== Сделайте тесты ==

Тесты просто необходимо включать в continuous integration процесс, в противном случае вы не можете быть уверены в качестве и работоспособности своего проекта. Чем тестов больше, тем лучше, в разумных пределах конечно. Основными двумя ограничителями на количество тестов будет:
* время интеграции — сборка по-прежнему должна оставаться быстрой, основное тестирование можно перенести «на ночь»,
* наличие автоматизированных тестов — не все тесты требуют автоматизации, нет смысла делать автоматизированные тесты только для самих тестов, они должны быть целесообразны.

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

Именнно присутствие тестов одно из отличий интеграции от нажатия кнопки Build в вашей любимой IDE.

== Интеграция на специальной машине ==

Организовывать процесс необходимо на специально выделенной машине.
Такая машина по своей конфигурации и набору прикладных программ должна максимально соответствовать окружению в котором проект будет развернут (production enviroment). Очевидно, что полного совпадения достичь практически невозможно — маловероятно, что эксплуатироватся программа будет на машине с установленными средствами сборки, тестирования и проч. Но точное совпадение версий операционных систем (и сервис паков) необходимо.

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

= Методы =

== Continuous Integration сервер ==

Хотя в принципе практика continuous integration не требует никакого технического и программного обеспечения, гораздо удобнее, проще и дешевле наладить процесс с использованием таких средств. Такие средства называются сервера интеграции (continuous integration server)- специализированные приложения для автоматизации данного процесса.

Наиболее известный из серверов интеграции пожалуй [[CruiseControl]]. [[CruiseControl]] это сервер для интеграции приложений на java, написанный на java. Так же широко распространен его собрат (точнее портированная версия) под .NET — [[CruiseControl.NET]].

Ниже приведена схема организации такого сервера интеграции:
<graph>
digraph G{
rankdir=LR

Trigger [shape="box", style="filled", fillcolor="green", label="Trigger", URL="#Trigger"]
BuildLoop [shape="box", style="filled", fillcolor="yellow", label="Build Loop", URL="#Build_Loop"]
Report [shape="box", style="filled", fillcolor="yellow", label="Reporting App", URL="#Report"]
ExtApps [shape="box", style="filled", fillcolor="yellow", label="External Applications", URL="#Инструменты"]
Logs [shape="box", style="filled", fillcolor="yellow", label="Logs", URL="#Logs"]
Team [shape="box", style="filled", fillcolor="green", label="Team", URL="#Team"]

subgraph cluster_machine{
node [style=filled];
label = "Build Machine";
URL="#Build_Machine"

subgraph cluster_server{
node [style=filled];
BuildLoop -> Report;

label = "CI Server";
URL="#Continuous_Integration_сервер"
color=blue;
}

ExtApps->BuildLoop; /*->Logs;*/
ExtApps->Logs->Report;
color=blue;
}

Trigger->BuildLoop;
BuildLoop->ExtApps;
Report->Team;
}
</graph>

== Ручной процесс ==

Хотя решение с выделенным сервером для continuous integration кажется простым и дешевым, у него есть противники. Точнее, сторонники ручного процесса. Один из таких Джеймс Шор (James Shore) в своей статье [http://www.jamesshore.com/Blog/Continuous-Integration-on-a-Dollar-a-Day.html Continuous Integration on a Dollar a Day] пишет, как правильно организовать continuous integration процесс без специализированных приложений, вроде [[CruiseControl]]. В этой статье мы не касаемся данного вопроса.

= Процесс интеграции =

Continuous integration процесс состоит из нескольких этапов, некоторые из которых обязательны, другие нет:
* [[#Trigger|Trigger]] — обязателен
* [[#Update|Update]] — обязателен
* [[#Analyse|Analyse]] — не обязателен
* [[#Build|Build]] — а как без него?
* [[#UnitTest|UnitTest]] — крайне желателен
* [[#Deploy|Deploy]] — нужен по обстоятельствам
* [[#Test|Test]] — не обязателен, но крайне желателен
* [[#Archive|Archive]] — желателен
* [[#Report|Report]] — обязателен

== Trigger ==

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

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

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

== Update ==

На данном этапе CI сервер делает update своей локальной копии исходного кода проекта. В процессе update выясняются изменения в коде (и не только) произошедшие с последненй интеграции. Выяснение изменений необходимо для того, чтобы в случае сбоя можно было легко выяснить причину и найти ответственного.

== Analyse ==

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

Данный этап является необязательным для процесса continuous integration, но в случае его наличия можно получить дополнительный преимущества от введения практики в виде метрик по коду. Данный этап подразумевает не только получение статических характеристик кода, но и их включение в отчеты создаваемые сервером интеграции (о отчетах смотрите [[#Report|здесь]]).

== Build ==

Один из основных этапов процесса это сборка проекта. Здесь происходит компиляция (трансляция) исходных кодов в исполнимые файлы или какой-то другой результат. Поскольку сервер интеграции представляет собой специально выделенную машину (смотрите [[#Интеграция_на_специальной_машине|здесь]]) со строго определенной конфигурацией, результат только этой сборки можно считать конечным. Больше никаких «Проект собирается на моей машине!». Есть только одно место, где проект может собираться — это интеграционный сервер.

Естественно сборка является обязательным этапом интеграции.

== UnitTest ==

В методологии Extreme Programming модульное (unit) тестирование является неотъемлемой частью разработки приложения. Модульные тесты изначально автоматизированы, их включение в процесс интеграции крайне желательно. Поскольку часто у разработчиков нет времени или желания запускать такие тесты до того как изменения отправлены в систему контроля версий, дополнительное их исполнение никогда не будет лишним.
Дополнительную информацию можно извлечь, измеряя покрытие модульных тестов. Эта метрика поможет лучше контролировать качество выпускаемого продукта.

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

== Deploy ==

После того как мы убедились в некоторой работоспособности проекта — он собирается (этап [[#Build|Build]]) и все модульные тесты проходят ([[#UnitTest|UnitTest]]) проект необходимо «развернуть». В случае веб-приложения это выкладывание на веб-сервер (сервер приложений) и запуск. Для GUI приложений это (пере)установка в системе.

Этап развертывание должен проходить как можно более «чисто», подробнее смотрите [[#Интеграция_на_специальной_машине|здесь]]. При этом для последующего тестирования часто необходимо привести приложение в некое «стандартное» состояние:
* «залить» дамп базы
* настроить в стандартном режиме
* убрать следы предыдущей деятельности приложения

== Test ==

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

После прохождения регрессионных тестов можно считать, что интеграция прошла успешно и в проект не внесено правок, которые могут привести к его неработоспособности (здесь все зависит от вашего набора тестов модульных и функциональных). В противном случае интеграция не успешна — код содержит ошибки и требуется его исправление/доработка.

Тестирование это один из «фатальных» этапов процесса, ошибка на котором означает сбой сборки. Всего есть несколько таких «фатальных» этапов:
* [[#Build|Build]] — проект не собирается
* [[#UnitTest|UnitTest]] — модульные тест не прошли или покрытие упало ниже заданного уровня
* [[#Test|Test]] — регрессионные тесты не прошли или покрытие упало ниже заданного уровня

Иногда к ним присоединяют этап [[#Analyse|Analyse]] — если в коде обнаружено несоответствие стандартам кодирования, то это является ошибкой.

== Archive ==

После того как достигнута максимальная уверенность в качестве исходного кода необходимо сохранить его. Это можно сделать, например, посредством меток в системе контроля версий. Так же необходимо сохранить бинарные файлы проекта. Они могут понадобиться, если нужно будет воспроизвести ошибку в конкретной версии и для ручного тестирования.

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

== Report ==

В конце идет важный этап генерации и публикации отчетов. Отчеты включают в себя следующее:
* причина сборки — например изменения в репозитории
* изменения в исходных кодах — здесь возможны два варианта изменения от последней сборки или от последней успешной сборки
* отчеты по статическому анализу кода — все результаты какие есть
* лог сборки
* лог модульных тестов — какие тесты прошли и, что важнее, какие не прошли
* лог регрессионных тестов — аналогично модульным тестам
* статистика сборок проекта:
** общее число удачных/провальных сборок
** распределение удачных/провальных сборок во времени
** статистика результатов статического анализа кода
* все другие метрики используемые и собираемые в проекте — это поможет менеджеру проекта видеть все и сразу

Механизм публикации отчета может быть разный и даже не один. Это может быть IRC или jabber бот, рассылка по электронной почте, публикация на web или ftp сервере, специализированные клиенты позволяющие узнать статус сборки.

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

Для правильной организации данного этапа важно понимать кого и как необходимо оповещать о результатах интеграции. Здесь надо выбрать между двумя крайностями — оповещать всегда или никогда. Примерное решение этой задачи будет таким:
* разработчики — минимум при сбое интеграции, в противном случае, как разработчик узнает, что внесенные им изменения сломали код? Конечно, можно оповещать и всегда, это зависит от частоты сборок.
* тестировщики — если они входят в команду, то оповещать тогда же, когда и разработчиков, ведь иногда ошибки могут быть и в тестах. Если практикуется независимое тестирование вообще не оповещать их или оповещать при окончании интеграции.
* менеджер проекта — сугубо по желанию

= Профиты =

Так какую пользу можно получить о внедрения непрерывной интеграции в своем проекте?

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

Больше никаких «Это работает на моей машине!». Если что-то не работает на сборочном сервере — значит оно не работает вообще. Аргументы программиста, что у него все работает в данном случае не помогут. Сервер интеграции становиться судьей в таких вопросах и этот судья беспристрастен.

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

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

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

= Continuous Improvement =

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

= Ссылки =

== Публикации ==

* [http://www.martinfowler.com/articles/continuousIntegration.html Continuous Integration] — статья Мартина Фаулера (Martin Fowler) по Continuous Integration
* [http://www.jamesshore.com/Blog/Continuous-Integration-on-a-Dollar-a-Day.html Continuous Integration on a Dollar a Day] — статья Джеймса Шора (James Shore) о ручном методе интеграции
* [http://blogs.msdn.com/mswanson/articles/169058.aspx Automated Continuous Integration and the Ambient Orb] — статья Майка Свонсона (Mike Swanson)
* [http://www.custis.ru/docs/publishing/secr-2008/article-ci.pdf «Введение в непрерывную интеграцию или каша из топора»] — статья Андрея Сатарина, представленная на конференции [http://secr.ru/ SEC(R) 2008]. Так же доступна [http://www.custis.ru/docs/publishing/secr-2008/talk-ci.pdf презентация] и [http://www.custis.ru/docs/publishing/secr-2008/talk-ci-handout.pdf презентация-handout].
* [http://c2.com/cgi/wiki?ContinuousIntegration c2.com] — статья по Continuous Integration в wiki на c2.com
* [http://en.wikipedia.org/wiki/Continuous_Integration en.wikipedia.org] — статья по Continuous Integration в Wikipedia
* [http://ru.wikipedia.org/wiki/Непрерывная_интеграция ru.wikipedia.org] — статья по непрерывной интеграции в Википедии

* [http://www.pragprog.com/titles/auto/pragmatic-project-automation www.pragprog.com] — книга «Pragmatic Project Automation». [http://media.pragprog.com/titles/auto/scheduled.pdf Глава], которая посвящена непрерывной интеграции доступна бесплатно.
* [http://www.amazon.com/Continuous-Integration-Improving-Addison-Wesley-Signature/dp/0321336380/ref=sr_1_1?ie=UTF8&s=books&qid=1206124954&sr=8-1 www.amazon.com] — книга Пола Дюваля (Paul Duvall) о непрерывной интеграции, получившая Jolt Award в 2008 году
* [http://www.ozon.ru/context/detail/id/3851770/ www.ozon.ru] — эта же книга изданная на русском языке

== Инструменты ==

=== Сервера интеграции ===
* [http://cruisecontrol.sourceforge.net CruiseControl] — сервер интеграции для Java (см. так же [[CruiseControl]]).
* [http://studio.thoughtworks.com/cruise-continuous-integration ThoughtWorks Cruise] — коммерческий сервер интеграции от компании ThoughtWorks (есть бесплатная версия).
* [http://ccnet.sourceforge.net CruiseControl.NET] — сервер интеграции для .NET (см. так же [[CruiseControl.NET]])
* [http://cruisecontrolrb.thoughtworks.com CruiseControl.rb] — сервер интеграции для Ruby.
* [http://hudson.dev.java.net Hudson] — open-source сервер интеграции, создан как альтернатива [[CruiseControl]]. Функциональность расширяется плагинами.
* [http://bitten.edgewall.org Bitten] — open-source сервер интеграции написанный на [[Python]], интегрируется с [[Trac]].
* [http://www.jetbrains.com/teamcity/index.html TeamCity] — коммерческий сервер интеграции от компаниии JetBrains для java и .NET (есть бесплатная версия).

=== Инструменты сборки ===
* [http://ant.apache.org Ant] — средство сборки для Java
* [http://maven.apache.org Maven] — средство сборки для Java
* [http://nant.sourceforge.net/ NAnt] — аналог Ant под .NET

=== Статический анализ ===
* [http://pmd.sourceforge.net PMD] — анализ кода Java
* [http://findbugs.sourceforge.net Findbugs] — анализ кода на типичные ошибки
* [http://www.redhillconsulting.com.au/products/simian/ Simian] — поиск повторов (copу+paste) в коде Java
* [http://www.gotdotnet.com/team/fxcop/ FXCop] — анализ кода .NET
* [http://qalab.sourceforge.net/index.html QALab] — объединение логов нескольких инструментов анализа кода, сбор статистики
* [http://www.panopticode.org/ Panopticode] — объединение логов нескольких инструментов анализа кода для Java, графическое представление результатов

=== Модульное тестирование и покрытие ===
* [http://junit.org JUnit] — де-факто стандарт модульного тестирования Java
* [http://testng.org TestNG] — инструмент нового поколения для модульного тестирования Java
* [http://www.nunit.org/ NUnit] — модульные тесты для приложений .NET
* [http://cobertura.sourceforge.net Cobertura] — измерение покрытия кода модульными тестами для Java
* [http://www.atlassian.com/software/clover/ Clover] — анализ покрытия кода тестами для Java
* [http://www.cenqua.com/clovernet/ Clover.NET] — анализ покрытия кода тестами под .NET

== Юмор ==
* [http://www.youtube.com/watch?v=XV5fViOoV_ «Every build you brake»] — песня в исполнении Роя Ошерова (Roy Osherove)
* [http://www.youtube.com/watch?v=Azl4nqLn4-Y «Hitler’s nightly build fails»] — пародия о неудавшейся ночной сборке
* [http://www.buildsonmymachine.com/ «Builds on my machine»] — юмористическая компания в поддержку практики непрерывной интеграции (смотрите так же [http://www.wheresthebuild.com/] и [http://www.youbrokethebuild.com/])

[[Категория:Программирование]]
[[Категория:Тестирование программного обеспечения]]
{{replicate-from-custiswiki-to-lib}}

Линус Торвальдс о GIT на Google Talks

2009-05-30T06:17:12Z

Andrew: /* См. также */ Статьи о Subversion

[[Image:Linus-git-googletalk.0-00-04.098.jpg|right]]

<blockquote>
Перевод доклада Линуса Торвальдса о системе контроля версий <tt>git</tt> на «''Google Talk''»
<ref>Оригинальное видео доклада http://www.youtube.com/watch?v=4XpnKHJAok8</ref>,
выполнен сообществом компании [http://team.custis.ru «Заказные ИнформСистемы»].
</blockquote>

[[Image:Linus-git-googletalk.0-00-11.269.jpg|center]]
[[Категория:Системы контроля версий]]

== Представление ==

[[Image:Linus-git-googletalk.0-00-19.731.jpg|framed|right| Эндрю Мортон. Один из ведущих разработчиков ядра Linux. Работник Google]]

'''''Эндрю:'''''
Спасибо всем пришедшим, большинство из вас вероятно уже слышали
о Линусе Торвальдсе, а те, которые не слышали — это люди с Макинтошами на коленях.
Это парень, который прется от издевательств над людьми.
Его последняя выходка — создание СУВ<ref>система управления версиями</ref>, которая явно создана для того,
чтобы вы почувствовали себя менее умными, чем до знакомства с ней.
Спасибо, что снизошли до нас сегодня, Линус.
Последние дни я получал письма от людей, вопрошающих:
«Где Линус? Почему он не берет мою ветку? Он меня больше не любит… =(»


И вот, он пришел в мой офис сегодня днем, и сказал: «а чем ты вообще тут занимаешься?!»
О, спасибо вам, что тратите на нас свое время.
И вот, Линус пришел сегодня, чтобы объяснить нам,
какого …, он написал такие тулы, гм,
что только он тот избранный, кто настолько мудр, чтобы понять, как ими пользоваться.

[[Изображение:linus-git-googletalk.0-00-51.199.jpg|framed|center| тут все апплодируют, апплодируют…]]

== Вводное слово ==
[[Изображение:linus-git-googletalk.0-01-15.165.jpg|framed|left|Линус Торвальдс.]]

'''''Линус:'''''

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

Так вот, я не буду говорить про ''Ядро''<ref>Проект Linux Kernel.</ref>, просто потому, что оно слишком большое,
чтобы рассказать о нем за час, хотя похоже Эндрю сделал это пару дней назад.
Вместо этого я расскажу вам про [[EnPedia:Git_(software)|git]], систему управления версиями,
которую мы используем для Ядра.

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


Я не знаю, как тут у вас, на ''Google talks'', все это происходит,
я скажу просто — меня не стесняйтесь.
А если ваш начальник потом вас пристрелит — это будет уже ваша проблема.

== Credits ==

[[Изображение:Linus-git-googletalk.0-02-21.683.jpg|framed|Потому что Линус любит заставлять людей думать, что он скромный|left]]
Сначала я хочу раздать несколько отзывов и благодарностей.

О [[CVS]] я будут отзываться только в очень-очень отрицательном ключе,
потому что я, когда проектировал <tt>git</tt>, во многих ситуациях
использовал (в контексте СУВ) подход «что бы тут сделал Иисус», а иногда и «что бы тут CVS никогда не сделала».

Я никогда не использовал CVS при разработке ядра.
За последние десять лет для поддержки ядра
мы использовали только тарболы<ref>tarballs — несжатые tar-архивы</ref>
и патчи<ref>patch — файлы изменений</ref>,
которые оказались лучшими СУВ, чем CVS,
но я «покончил с CVS» после семилетнего опыта использования ее
в коммерческой компании, и я страстно ненавижу эту систему.

Когда я сказал, что страстно ненавижу CVS, я должен также сказать, что если в аудитории есть пользователи SVN ([[EnPedia:Subversion (software)|Subversion]]),
то вы, возможно, захотите уйти.
Поскольку моя ненависть к CVS означает, что я считаю Subversion самым
бесцельным проектом, так как основной девиз Subversion некоторое время был
«Сделанный по-уму CVS» или что-то вроде этого.
А если вы начинаете с такого слогана, то вы никуда не сможете прийти.
Это так, потому что CVS невозможно сделать «правильным».

Это была негативная часть.

А вот с благодарностью я упомяну о [[EnPedia:BitKeeper|BitKeeper]],
хотя я понимаю, что по мнению многих, вокруг ''BitKeeper''’а было
много проблем и споров да и «развод» с ним был во многих смыслах неприятен.
Но по-моему, наш развод с BitKeeper-ом был
вполне полюбовный, хотя снаружи это казалось иначе.
И BitKeeper не только стал первой системой контроля версий,
которая показалась мне вполне достойной,
но, более того, показал мне, в чем была его основная идея
и как с ней можно реально работать.
И хотя <tt>git</tt> во многом, в том числе технически, очень-очень сильно отличается от
BitKeeper (это было специально задумано, чтобы убедить всех, что это
не клон BitKeeper), многие процессы используемые нами с <tt>git</tt>,
взяты из BitKeeper.

Кстати, вы используете BitKeeper здесь, в Google? Я сомневаюсь.
Насколько я знаю, BitKeeper — это единственная коммерческая распределенная СУВ,
и поэтому, если вам-таки нужна именно коммерческая система,
то вам стоит использовать BitKeeper.

Я также хотел бы заметить, что я разрабатываю <tt>git</tt> чуть больше двух лет,
но хотя я запустил проект, разработал архитектуру и начальный код,
на протяжении последних полутора лет его поддерживает
гораздо более славный парень, японец ''Junio Hamano'',
и именно он сделал <tt>git</tt> более доступным для простых смертных.
Ранние версии <tt>git</tt> действительно требовали некоторое количество
«ментальных пунктов» мозгосилы.
C тех пор он стал гораздо проще.

В общем, это мой обычный подход —
все остальные делают все возможное, а я сам могу просто сидеть и потягивать
ПинаКоладу<ref>Пинья колада (исп. Piña colada), также ошибочно называемый пинаколада/пиноколада и т. п. — традиционный карибский алкогольный коктейль содержащий ром, кокосовое молоко и ананасовый сок.</ref>,
ну и типа люди то же вроде как-то при деле…

На этом благодарности окончены, всех вышеперечисленных откладываем в сторону.

== Content ==

[[Изображение:linus-git-googletalk.0-06-23.653.jpg|framed|right| Он набросал эту презентацию прошлой ночью, не ждите здесь чуда]]
Вот этому слайду уже один день.
Я вообще не делал презентацию прошлой ночью, потому что прошлой ночью
я пьянствовал, отрывался и ел суши. Вот.

И тем не менее, в презентации
речь пойдет о реализации надежной, высокопроизводительной распределенной
системы управления содержимым, и ключевое слово здесь — «распределенная».
Я сначала попытаюсь объяснить, почему распределенность так важна.
Если мы потом к этой теме не вернемся, я буду действительно счастлив.

И ничего страшного, если мы так и не разберем, как <tt>git</tt> устроен изнутри.
Учить пользоваться <tt>git</tt>’ом я тоже не буду.
Ну есть же у вас такая штука, которую вы делаете, «google.com»,
и в ней есть такое место, куда можно вводить буквы, и если вы введете туда «git»
и нажмете кнопку «Мне повезет!», вы обязательно попадете [http://git-scm.com/ на официальный сайт <tt>git</tt>],
на котором есть и вводные обучающие курсы и руководство пользователя в HTML-формате.
В общем, если вы хотите научиться пользоваться <tt>git</tt>, вам нужно первым делом туда,
а не на этот доклад.

Но, как я уже сказал, ничего страшного, если мы отклонимся в сторону от темы
из-за ваших вопросов.

== Content Advisory ==
[[Изображение:Linus-git-googletalk.0-08-05.443.jpg|framed|left|Линус критичен и к программам и к людям]]

Я вам уже озвучил эти примечания к заголовкам; я использую сокращение [[EnPedia:Source_Code_Management|SCM]] в
значении «''source code management''/управление исходным кодом»,
что то же самое, что контроль версий. Некоторые думают, что SCM означает
«Управление конфигурациями/''software configuration management''»
и включают сюда не только контроль версий, но и управление релизами и все такое;
но я сейчас буду рассказывать не об этом, хотя <tt>git</tt> вполне подходит и для этого.

С [[CVS]] мы уже разобрались. Вы можете не соглашаться со мной сколько хотите, но в течение этого доклада
все, кто не согласен со мной, по определению — тупые уроды.
Помните об этом!
Вы будете вольны делать и думать все что захотите, когда я закончу доклад.
А сейчас я рассказываю свое единственно правильное мнение,
так что пользователи CVS, если вы действительно его так любите,
уйдите с глаз моих долой. Вам надо обратиться в психушку или куда-то еще.

== Background ==
[[Изображение:Linus-git-googletalk.0-09-24.327.jpg|framed|right|от BitKeeper к <tt>git</tt>]]

Теперь, перед тем как начать говорить о самой сути «Распределенности»,
что, по-моему, архиважно, нельзя не упомянуть об истории <tt>git</tt>,
потому что если люди что-то и слышали о <tt>git</tt>,
то это, в первую очередь, историю его возникновения.

Во-первых, я на самом деле вообще не фанат SCM.
Я никогда особо не интересовался системами контроля версий, и думал, что это зло,
пока не наткнулся на ''BitKeeper'', который оценил по достоинству; и,
в некотором смысле, именно поэтому <tt>git</tt> намного лучше всего остального,
ведь мой мозг не страдал долгие годы, думая, что [[CVS]] делает что-либо разумное.

Мне понадобилась замена для BitKeeper.
Причина в том, что BitKeeper — это коммерческий продукт,
но ''BitMover'' и ''Larry McVoy'' разрешили использовать его бесплатно для open-source
продуктов, как вы, возможно, знаете; единственным ограничением было то,
что его нельзя было исследовать (''reverse engineer'') и нельзя пытаться создать конкурирующий продукт.

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

Но не все были согласны со мной.
Все они тупые уроды, но как бы там ни было,
они подкинули проблем,
и это в результате привело к тому, что мы с ''Larry'' несколько раз
поговорили по телефону и в конце концов договорились прервать сотрудничество,
дабы не ухудшать отношения.

Тогда, примерно 2 года назад, я выпустил релиз <tt>Linux 2.6.12-rc2</tt> и сказал,
что не продолжу разработку Linux, пока у меня не будет замены BitKeeper’у,
для управления исходным кодом.

Одним из способов замены был возврат к tar-архивам и патчам,
но все были категорически против.

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

Если система не распределенная, ее не стоит использовать, это же очевидно.

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

Честно говоря, та малышка [BitKeeper] прекрасно заботилась обо всем.
Полно СУВ которые не гарантируют, что то, что вы из них достаете,
является в точности тем, что в них положили.
Вы можете никогда и не узнать, что у вас повреждена память или жесткий диск.
А заметите это, только когда получите назад поврежденный файл.
Причем сама система контроля версий за этим вообще не следит.
И такое — совсем не редкость.
Да, это встречается очень, очень часто.

Проблема быстродействия: одной из систем, которая мне более-менее понравились,
была система [[EnPedia:Monotone_(software)|Monotone]], о которой, кстати, когда-то вроде был доклад в Google,
хотя может я и ошибаюсь; так вот, в ней было много интересных идей,
но производительность была просто ужасна,
так что попробовав ее один день, я понял, что она мне не подходит.

В результате, я решил, что сам за две недели смогу написать что-то получше,
и не ошибся.

== Distribution ==

[''Показывает слайд «Distribution» с картинкой'']

[[Image:Linus-git-googletalk-slide-distribution.jpg|framed|Это не просто хорошая идея. По-другому просто не будет работать!]]

Теперь перейдем к ''Распределенности'', и это худший слайд из всех,
и мне стыдно за него, но проблема в том, что ''Распределенность''
действительно очень важна,
но у меня никогда не получается сделать об этом нормальный слайд.
Частично это из-за моих скудных художественных способностей,
которые вы видите перед собой на экране,
но на самом деле это действительно трудно объяснить.

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

[''слушатели поднимают руки'']

Большинство из вас разрабатывают ядро?
Нет?
Хорошо, примерно десять человек подняли руки.

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

Поэтому, например, я Subversion даже
трехметровым багром трогать не буду.
В Subversion большой репозиторий, куда все обязаны складывать свои данные.
А централизованная модель просто не работает,
когда… давайте взглянем на некоторые такие случаи.

[''Показывает слайд «Distribution» с пунктами'']

[[Image:Linus-git-googletalk-slide-distribution2.jpg|frame|Слайд «Distribution» с пунктами]]

Я сказал, что распределенность — это гораздо больше, чем просто работа в оффлайн,
но это, пожалуй, понять проще всего:
вы можете взять по-настоящему распределенную SCM с собой в самолет и,
даже если в нем нет ни wi-fi, ни спутникового интернета,
вы просто продолжаете работать — вы можете посмотреть любые логи,
вы можете фиксировать изменения, вы можете делать все, что вы бы делали,
если бы вы были подключены прямо к магистральному каналу с гигабитным Ethernet.
И это действительно важно.

Это вдвойне важно, когда над одним и тем же проектом работают
сотни и тысячи людей, и они даже не обязательно должны быть все отключены
от сети, просто на практике они на самом деле не всегда имеют хорошую связь.
Так что работа в оффлайн — это один из аспектов распределенности,
и даже если работа не всегда идет оффлайн,
очень важно иметь возможность делать все, что вам нужно,
находясь в любом месте и даже не имея возможности подключиться к серверу.

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

И это действительно очень важно и очень сильно отличается от работы в CVS,
где ветвление считается уделом настоящих мастеров.

Кто из вас когда-либо пользовался CVS?

[''Слушатели поднимают руки'']

Понятно, все. А кто когда-нибудь по-настоящему создавал ветку, а потом объединял изменения в CVS?

[''Слушатели поднимают руки'']

Хорошо.
Отмечу, что далеко не все, хотя и гораздо больше, чем я ожидал.

Ну и кому из вас понравилось осуществлять этот процесс?

[''смех'']

Понятно, все-таки нескольким понравилось.

Считается, что это сложная операция. В CVS, когда вы объединяете ветки (а я делал это, избегал как мог, но приходилось),
вы планируете это на неделю вперед и, как правило, оставляете на это целый день.

Разве я не прав?
Что-то я не вижу, чтобы многие говорили «Нет, это очень просто, мне нравится это делать».
Это отвратительно!

Обязательно нужно понять, что в распределенной системе каждый человек работает
со своей отдельной веткой.
И это не страшно, вам даже не надо что-то специально настраивать,
так устроено изначально.

На самом деле, в <tt>git</tt> мы так любим ветки, что многие держат их по 10-15 штук,
потому что когда вы понимаете, что у вас по-любому будет отдельная ветка,
вам уже все равно, сколько их будет, и вы делаете отдельные ветки
для экспериментов и отдельные для поддержки.
Так что ветвление гораздо более свойственно распределенным системам.

Еще одна вещь, которая мне кажется важной, — это то, что распределенная система
в силу своего устройства более надежна.

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

Я очень сомневаюсь, что все так делают.
Но это по-настоящему работает только в распределенных системах.
Если вы пользуетесь CVS, вы не можете так сделать, если вы используете…
кстати, чем вы здесь пользуетесь?

Perforce?… [[EnPedia:Perforce|Perforce]]. Ну да, извините.
Да, он, конечно же, лучше, чем [[CVS]].

[''Слушатели смеются'']

Но все равно это по сути CVS.

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

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

И что это значит?
Поскольку вы не хотите, чтобы все подряд правили данные в центральном
репозитории, из-за того, что большинство людей — идиоты, то вам приходится выделять
людей, которые, по-видимости, идиотами не являются.
И чаше всего в этой группе оказывается слишком мало людей, потому что очень
сложно понять, насколько человек шарит, и наоборот,
даже если эта группа будет очень мала,
проблемы у вас все равно будут.

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

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

И потом, если окажется, что вы сделали что-то полезное, вы можете сказать
людям: «''Эй, тут в моей ветви все работает в десять раз быстрее, чем у всех остальных,
так что ня-ня-ня, не хотите взять мой код?''».
И народ берет.

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

Вы избавитесь от кучи проблем.

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

То есть Распределенность — это на самом деле ключевой момент для любой из
СУВ, которые стоит использовать.

Так что немедленно избавьтесь от Perforce!

[''Апплодисменты'']

Да, может и жалко, но это архиверно!

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

'''Из зала:'''

[[Image:Linus-git-googletalk.0-21-39.872.jpg|frame|right|И как вы собираетесь это делать?]]

{{question}} Вопрос. И как вы собираетесь это делать?
Если у вас есть эта монстрообразная, страшно огромная база кода
и вы хотите использовать ее, не останавливая
другие дела на шесть месяцев, как вы собираетесь это делать?

'''Линус:'''

Не отходите от микрофона, потому что я не совсем понял ваш вопрос.
Он ушел, ну ладно.

«Как вы собираетесь это делать?» — Ну, вот пример реальной распределенности:
у вас есть команда из пяти человек, которые работают над
одной небольшой конкретной вещью.

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

Вы можете этого достичь множеством способов.
В CVS один из наиболее распространенных подходов — не делать коммитов вообще,
поскольку возиться с ветвями очень нудно.

То есть вы не делаете коммиты, пока код не пройдет абсолютно все тесты.
Или например, в вашей компании строгое политика коммитов:
«нельзя делать коммиты пока они не пройдут весь набор тестов»,
а между прочим все тесты будут выполняться два часа, жесть!

Да, вам не позволяют делать коммиты.
И это происходит почти в каждой компании.
Я уверен, что это так даже у вас, в Google.
У вас вероятно есть строгий набор тестов и вам нельзя делать коммиты, пока
все тесты не будут пройдены, а это приводит к тому, что на практике люди вносят
изменения по одной строчке и не тестируют, потому что знают, что изменения в
одной строчке скорее всего ничего не сломают.
Да, бывает и так.

Такой подход, конечно — ужас-ужас!
Это означает, что вы делаете коммит огромного числа изменений за раз,
потому что работали над этими изменениями две недели.
И в итоге у вас три человека, которые делают одно и то же, потому
что они не видят изменений от других, пока не сделают коммит своих.
Это часто происходит, это происходит везде, это жуть!

Другой вариант — это использовать ветви, пусть даже в централизованной среде.
Но ветви всегда обрываются, так как их слишком дорого поддерживать,
так что у вас не получится разрабатывать в них экспериментальную функциональность.
Вы никогда заранее не знаете, потребуется ли на что-то один день или две недели,
ведь почти всегда любой программист скажет: «Ха, я сделаю это за 48 часов».
А потом выясняется, что «не-а, не могу».

Но так как вы думаете, что сможете сделать это за 48 часов, вам очень лень
создавать ветвь, даже в таких системах, в которых это делать удобнее, чем в CVS.
И вы этого не делаете, потому что думаете, что как-нибудь справитесь с этим
и вы возвращаетесь к случаю № 1, но даже если вы решите создать ветвь, то будете
менять содержимого репозитория и для всех остальных,
потому что в централизованной среде ветви глобальны.

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

В общем, в любом случае, успеха вы не добьетесь.

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

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

И эта модель гораздо лучше для разработки.

И это модель, которая используется в разработке ядра Linux.
Оказывается, что во многих местах нам не нужна вся эта мощь, даже в ядре.
И люди обычно не обмениваются обновленным кодом внутри одной группы, но иногда
случается, например, что те, кто работает над сетью, иногда сталкиваются с
людьми, которые работают над NFS, и то, что они могут синхронизироваться,
действительно помогает.
То есть это действительно помогает!

У кого-то еще есть вопрос?

[[Image:Linus-git-googletalk.0-27-03.671.jpg|frame|right|Похоже, что все эти правила и ограничения просто переместились или стали неявными.…]]

'''Из зала:'''

{{question}} Похоже, что все эти правила и ограничения просто переместились или стали неявными.
Да, у каждого есть доступ и все играются со своими ветвями в песочнице, но к вечеру
ветви нужно соединять и разрешать все конфликты чтобы не было 80
миллиардов вариантов каждого линуксового ядра.

'''Линус:'''

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

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

Через сеть доверия.

Если вы когда-нибудь занимались какой-то работой по безопасности
и не использовали концепцию сети доверия, то это был онанизм,
а не работа.
Я не знаю, чем вы там занимались, но поверьте мне, это единственный способ,
который дает безопасность и также единственно верный подход
в разработке ПО.

В своей работе я не доверяю всем без исключения.

Более того, на самом деле я крайне циничен и недоверчив.

Я думаю, большинство из вас полностью некомпетентны.

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

Мне нужно доверять только 5, 10, ну может 15 людям.
Если у меня есть доверенная сеть, в которую входят эти 5, 10, 15 выдающихся
человек, и я знаю, что они выдающиеся, я могу забирать новый код
у них.
И мне не надо париться на эту тему.

Когда Эндрю присылает мне патчи, он не использует никакого <tt>git</tt>,
это в некотором роде недостаток, ну и что, он очень надежный человек.
Когда он просит меня принять обновленный код, он просто посылает мне
миллион патчей, я просто их применяю.
Иногда я не согласен с какими-то из этих патчей, но с другой стороны,
доверие означает, как это сказать… «доверять — значит прощать»? Я не знаю…
В общем, это означает, что вы должны соглашаться с решениями других людей.

И самое замечательное в доверии — это что оно создает сеть.
Именно здесь и появляется сеть доверия.

Мне нужно лишь несколько человек, которым я буду доверять.
А у них есть другие люди, которых они выбрали, типа — «тот парнишка шарит покруче
меня» — да, это хороший критерий того, от кого вам следует брать исправленный код.
Если у вас есть кто-то еще, кто шарит лучше вас, — вперед.
Это беспроигрышно.

Даже если окажется, что вы взяли какую-то чушь, кто-то там начнет
жаловаться, вы знаете, откуда вы взяли эти исправления, и вы можете просто
сказать это жалующемуся «хм, я просто скопировал это, иди к нему, он наверное знал, что делал».

[[Image:Linus-git-googletalk.0-30-08.466.jpg|frame|right|Именно так я и работаю…]]

Именно так я и работаю, скорее всего также действуют и мои поручики/заместители
<ref>В оригинале ''lieutenants'', поэтому часто в рунете помощников Линуса зовут «лейтенантами».</ref>.
Я забираю изменения по сетевой теме от одного человека, а он получает их от
множества других людей, с которыми он постоянно работает, и таким образом все
изменения приходят ко всем, и им не нужно собираться всем в одной точке.

Хотя в ядре все приходит в большей степени в одну точку, так, я думаю, сложилось
исторически, и на самом деле я всегда пытался поощрять пожелания людей заводить
больше деревьев, и у нас действительно есть отдельные деревья по производителям оборудования,
у нас есть специальное «-mm»<ref>Экспериментальная ветвь ядра Linux, специализированная на управлении памятью, см. [[EnPedia:Mm_tree]].</ref> дерево, в котором много выделенных «точек», просто так получается, что
моя точка привлекает, быть может, больше внимания, чем должна была бы.

Даже если что-то там не придет к этой одной точке, это значит, что
можно взять тысячи этих ветвей, игнорируя <tt>99.9%</tt> из них.
Зато вам интересно отслеживать, скажем пять ветвей, относящихся к областям, которыми вы интересуетесь.

И все это работает очень естественно.

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

Люди мыслят именно так.

Мы не знаем сотню людей.
У нас есть 5, 7, 10 близких личных друзей, ну ладно, пусть мы асоциальные гики,
поэтому у нас их двое, но это основы человеческого сотрудничества, то
что у нас есть те, кому мы действительно можем доверять,
это семья, это близкие друзья, и все это удобно и привычно, не нужно
держать в голове неестественную модель взаимодействия,
все подключаются естественным образом.
Поэтому работа с этой моделью сетевого доверия дает огромные преимущества.

[[Image:linus-git-googletalk.0-31-51.970.jpg|frame|right|Знаете ли вы о компаниях, которые используют распределенные системы у себя внутри?]]

'''Из зала:'''

{{question}} Знаете ли вы о компаниях, которые используют распределенные системы у себя внутри?
Похоже, тут есть вероятность «сепаратизма» в коде,
так как народ, разбредется по собственным песочницам, и
не будет вкладываться в основной ствол.

'''Линус:'''

Честно говоря, не так уж и много распределенных систем.
Это BitKeeper, очевидно использующийся коммерческими компаниями,
мы должны иметь в аудитории кого-нибудь, кто действительно знает, но что …
[''комментарий из аудитории''], ага,
HP использует такие системы как BitKeeper в проектах разработки принтеров.

Я уверен, что таких компаний немало.
В мире open-source ПО, есть пара распределенных
систем, которых стоит посмотреть прямо сейчас.
Очевидно одна из них — <tt>git</tt>.
И вы, конечно, должны выбрать ее.

Но есть и другая — Mercurial, которая на самом деле очень похожа по архитектуре.
Есть некоторые различия в деталях архитектуры и большие различия в реализации,
но в сухом остатке модели очень похожи.
Только <tt>git</tt> делает это лучше.

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

'''Из зала:'''

{{question}} А какие преимущества у компании, когда все играются в собственных песочницах?

'''Линус:'''

Я думаю, что есть полно компаний, считающих, что такие преимущества есть.

Я знаю это от инсайдеров, и не думаю, что многие компании
осознанно используют <tt>git</tt>, в смысле, чтобы решение по его использованию
было принято на уровне корпоративного стандарта.

Я знаю несколько компаний, которые внутри
используют <tt>git</tt>, не подозревая об этом, потому что они все еще держат
свои главные репозитории в Subversion, но многие разработчики затем
импортируют код в <tt>git</tt>, потому что <tt>git</tt> действительно хорошо выполняет слияния.
Так что вы можете взять дерево веток из Subversion, импортировать в <tt>git</tt>,
позволить <tt>git</tt> сделать слияние,
что было бы основной головной болью в Subversion,
зафиксировать изменения и фактически экспортировать их назад в Subversion,
и никто другой даже не узнает, что вы использовали <tt>git</tt>.
Немного грустно, но я слышал о многих,
работающих в компаниях в точности по этому сценарию.

А вот чтобы постоянно использовать <tt>git</tt> подряд в течении полугода или больше — таких людей пока еще мало.

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

Я думаю, что мы прошли переломный момент.
Git намного проще использовать, чем CVS, правда-правда!

Большинство людей склоняются к … э-мнэ-э, он проще в использовании, чем что-либо еще.
Это всего лишь,… забудьте это.
Вы не обязаны использовать все его мощные возможности,
некоторые из них могут
быть тем, что вы хотели бы объяснить и представить людям только
после того, как они преодолеют начальные трудности
понимания того, что действительно означает распределенность,
но основные вещи делать действительно легко.

[[Image:linus-git-googletalk.0-34-59.000.jpg|frame|right|Как вы сводите к минимуму конфликты слияний?]]

'''Из зала:'''

{{question}} Одна из характеристик централизованных систем — это то, что именно
тот разработчик, который должен коммитить, обязан также
провести слияние. Как с этим в <tt>git</tt>?
И как вы сводите к минимуму конфликты слияний?

'''Линус''':

Спасибо, что спросили меня об этом!
Это не вас ли я просил задать этот вопрос?

Одно из самых приятных свойств <tt>git</tt> это то, что он реально проще
разбирается со слиянием, чем все остальные системы.
Объединение ветвей в CVS происходит крайне мучительно, просто невыносимо.

По моим подсчетам ядро Линукса — это на самом деле один из крупнейших
проектов с открытыми исходниками.
У нас <tt>22 000</tt> файлов.

Мы используем <tt>git</tt> уже два года.
В течение этих двух лет у нас было в среднем <tt>4.5</tt> слияния в день!

Если бы слияние было бы сложным, то точно пользовались чем-то другим.
Так что <tt>git</tt> делает слияния простыми.

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

А другой чел поменял код так сильно и его версия настолько конфликтует с остальными
(такое бывает, правда не очень часто),
что я говорю: «Я мог бы это пофиксить, но мне лень».
В их области я не программирую — это не моя сфера интересов,
это сетевые технологии или что-то в этом духе,
я просто не могу разобраться и оценить этот код, не могу его тестировать,
так что просить меня разобраться с этим слиянием — просто глупо,
так дела не делаются.

Ага, комп с Виндой опять погас.

Итак, помните, что распределенная модель означает, что «особенных» нет.

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

И они разбираются.
Они знают, что делать, потому что это их изменения.

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

Зато они сами объединяют изменения, обновляют свое дерево файлов и говорят мне:
«Эй, теперь можешь забирать рабочий вариант», и я загружаю себе их версию.
Они прекрасно сделали всю работу за меня.

В этом-то и есть вся прелесть: ''они все сделали за меня''.
А мне достаются честь и хвала!
Далее мне просто нужно подсчитать третью составляющую — ''PROFIT!!!''

Все это аспект, естественным образом возникающий в распределенных системах,
это не особенность <tt>git</tt>. Да, <tt>git</tt> справляется со слияниями гораздо проще, чем все остальные,
но это свойство вытекает из самой распределенной модели.

[[Image:linus-git-googletalk.0-38-02.885.jpg |frame|right|…зачем вам так нужно иметь эту распределенную систему?]]

'''Зритель''':

{{question}} Слушай, я не совсем понимаю, зачем вам так нужно
иметь эту распределенную систему…
Ну да, вроде получаешь кучу преимуществ, по крайней мере
для коммерческой разработки, да и для разработки open-source наверно очень полезно,
поскольку каждый может работать сам по себе,
но, когда у тебя централизованная СУВ, общая структура директорий и файлов,
не окажется ли, что централизованная система с дешевыми ветками
даст тот же самый эффект?
Или такое просто невозможно?

'''Линус''':

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

Они не могут работать так же хорошо, как и распределенные системы!

Одна из проблем состоит в том, что у централизованных систем неизбежны проблемы
при совместной работе групп из разных мест.

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

Эээ… мда, я не могу показать вам демонстрацию,
да и не так уж она интересна,
но это ноутбук 4-5-летней давности.
Что-то типа ''Pentium-M 1.6 GHz''.

Я мог бы показать вам, что полный <tt>diff</tt> проекта Linux Kernel
на этом ноуте займет чуть больше секунды.

На моей основной машине, это уже будет меньше десятой доли секунды.

Это прирост производительности, которого вы никогда не добьетесь,
работая по сети.

Как только вы стали использовать сеть, хоть для пары пакетов,
вы уже впустую потратили производительность.

Так что если у вас децентрализованная система, и вы привыкли
делать <tt>commit</tt> или <tt>diff</tt> всего дерева исходников за 30 секунд,
то, может быть, 30 секунд вам не покажутся злом.

Но поверьте, когда вы привыкли делать это за одну десятую секунды,
30 секунд — это полный отстой.

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

Другая заморочка — это ветки. Даже если вы
очень эффективно реализовали ветвления, сам факт того, что вы создаете
ветки и каждый может их увидеть, потому что все централизовано, означает,
что волей-неволей вам не захочется делать никаких веток.

У вас будут проблемы с пространством имен.

Как вы назовете свою ветку?
Вы назовете ее «test»?
Ага-ага, уже есть 5000 других веток,
названных «test1», «test2», … «test5000», так что вам теперь придется
выдумывать новые правила именования
ваших веток, потому что у вас централизованная система
с централизованным пространством имен у ветвей,
что совершенно неизбежно при работе с централизованной системой.

Как же это работает в распределенной среде разработки?

Вы называете свою ветку «test», и все!
Ну на самом деле, вам не следовало бы ее так называть, веткам нужно давать имена
согласно их функциональности; называйте их кратко, благозвучно
и конкретно — что эта ветвь делает.

Git дает вам по умолчанию одну ветку под названием «master»:
красиво, коротко и ясно — это ваш основной ствол.

Но вы можете создать ветку под названием
«experimental-feature-x» — и все будет понятно.

Но в централизованной среде вы просто не сможете так сделать.
Вы не можете назвать ветку «experimental-feature-x».
Вы должны придумывать тупые, идиотские названия.

Я работал в компании, у которой были прекрасные скрипты для CVS,
настолько прекрасные, насколько это возможно, они помогали создавать ветки.
Вы даже могли создать ветку с помощью одной простой команды,
это не занимало много времени — система фиксировала имя вашей ветки,
добавляя к ней число.
Вы определяете базовое имя, говоря:
«это моя ветка, она делает то-то и то-то», и система называет
вашу ветвь: «то-то-и-то-то—56».

И система добавит тег/закладку там, где вы начали разрабатывать эту ветку,
потому что в CVS вам приходится это делать…
Это занимало некоторое время, но работало.

Вы можете так извращаться в централизованных системах, но вам не нужно этого делать!

Ваша система децентрализована, она просто работает.

Именно так все и должно работать.

Итак, я ничего не утверждаю, я не собираюсь вас убеждать переходить
на децентрализованную систему,
я просто констатирую факт: «Вы тупые уроды»!

Таков расклад.

Как бы то ни было, перейдем к слайду «Performance».

[[Image:linus-git-googletalk.0-43-15.833.jpg|frame|right|…сколько файлов осилит <tt>git</tt>?]]

'''Зритель''':

{{question}} Могу я задать вопрос?

'''Линус''':

Давай.

'''Зритель''':

{{question}} На самом деле, два вопроса.
Первый: сколько файлов осилит <tt>git</tt>?
а второй, представьте, что у вас здоровенная древовидная структура файлов в <tt>git</tt>,
возможно ли извлечь только часть этой структуры?

'''Линус''':

Отличные вопросы.

На самом деле, эти вопросы цепляют совсем другую тему,
хотя они связаны с производительностью.

Одно из особенных свойств <tt>git</tt> — отслеживание изменений всего содержимого,
и это отличает <tt>git</tt> даже от [[EnPedia:Mercurial_(software)|Mercurial]], несмотря на то, что они очень похожи.

Он никогда не отслеживает отдельный файл.
Вы не можете прослеживать изменения файла в <tt>git</tt>.

Ну, вы можете проследить изменения проекта, в котором один единственный файл.
Если в вашем проекте один файл, то у вас все получится,
но если вы отслеживаете изменения в десяти тысячах файлов, то <tt>git</tt> никогда не будет
возиться с ними по отдельности.

Git думает, что все вокруг — это единый проект.
Вся история в <tt>git</tt> основана на истории проекта целиком.

Отсюда — важные следствия для производительности.

Когда вы используете CVS, вполне нормально, хотя и глупо,
иметь один здоровенный репозиторий с миллионом файлов внутри.

Таким образом, в конце дня, поскольку CVS думает о каждом
из миллиона файлов по отдельности,
вы можете попросить CVS обновить только один единственный файл —
все это в рамках CVS-идеологии.
И это верно для множества других моментов.

Точно также работает и BitKeeper, и это является одной из его ошибок.

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

Поэтому <tt>git</tt> следит за всем, как за коллекцией файлов,
и если вы попросите историю конкретного файла,
<tt>git</tt> буквально начнет с глобальной истории и упростит ее.
Это очень эффективная система, вам даже в голову не придет что это так,
но в действительности, когда вы пытаетесь следить за миллионом файлов
в репозитории, а потом просите историю конкретного файла — это очень тормозит систему.
Таким образом, свойства масштабирования у <tt>git</tt> сильно отличаются от других систем,
благодаря этой фундаментальной особенности.

Мы работали с большими репозиториями.
Мы импортировали историю проекта KDE из SVN, может быть, не всего,
но уж <m>\frac34</m> точно.
И KDEнутые … эээ… ''Я не должен так их называть… Я не буду, поверьте, мне нравится KDE.''

Но они засунули все компоненты в один репозиторий!
Не слишком умно.
Получилось так, что тот репозиторий, который, думаю, весил 8 Гб под CVS,
в SVN разбух еще в три раза!
Ну может там было меньше 8 Гб под CVS, но он был действительно огромным.
Точно больше 4 Гб.
Git же сжал это безобразие до где-то 1.3 Гб.

Итак, <tt>git</tt> очень эффективен в обработке этого проекта,
почти все работает отлично, но не все и не всегда.

Система не заработает хорошо, если вы поместите миллион файлов
в один репозиторий при начальном клонировании.
Когда вы его запрашиваете, вы получаете его целиком.
Вы сваливаете все в один репозиторий, <tt>git</tt> думает, что это один обьект.
Не делайте так.

Если у вас есть множество компонентов, размещайте их в отдельные репозитории,
вы можете даже создать суперпроект, в котором содержатся указатели
на другие проекты, при этом что-то теряется в пользовательском интерфейсе,
но вы храните разные проекты по отдельности.
Тогда вы избежите проблемы «получения всего сразу».
Потому что с <tt>git</tt> вам придется получить все и сразу.

'''Из зала''':
{{question}} Как насчет разделяемого кода?

'''Линус''':

Если они все «расшарили» свой код, что вы можете сделать с помощью <tt>git</tt>,
если у вас действительно много «расшаренных» файлов,
то поскольку <tt>git</tt> внутри использует «файловую систему идентифицируемую содержимым»,
то если существуют одинаковые по содержанию файлы,
<tt>git</tt> будет использовать для них в точности один и тот же объект.
И сохранит вам тонны свободного места.

И у вас могут быть эти расшаренные объекты, и в тоже время
они могут храниться у вас как отдельные сущности.
Вы также можете хранить их в раздельных репозиториях,
но лежащих на одной разделяемой файловой системе.
Вы можете это сделать!

Если у вас действительно есть расшаренный код, ну например,
библиотека, которая используется в пяти разных местах,
то если вам стоить использовать поддержку супер-проекта, где у вас есть
один репозиторий <tt>git</tt>, который просто отслеживает остальные репозитории <tt>git</tt>,
(и он тоже может содержать например, разделяемую инфраструктуру сборки),
но при этом индивидуальные части остаются индивидуальными.

Это похоже на модули CVS.
В CVS модули не до конца индивидуальны, но это потому,
что в CVS каталог — это вещь, которая всегда сама по себе,
так что модуль CVS — это комбинация «каталожности» и их отслеживания,
но в целом вы можете думать об этом как о модулях CVS.

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

Возможно, я забыл ответить на какую-то часть вашего вопроса.

[[Image:linus-git-googletalk.0-49-34.467.jpg|frame|right|Можно ли извлечь из репозитория только часть файлов?]]

'''Из зала:'''

{{question}} Можно ли извлечь из репозитория только часть файлов, а не целый репозиторий?

'''Линус:'''

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

Неверно, что <tt>git</tt> не может обрабатывать большие проекты,
просто производительность будет не так хороша,
а вы будете иметь проблемы, которых можно было бы избежать.

Так что я пропускаю этот вопрос и возвращаюсь к теме производительности.

== Performance ==

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

''[показывает слайд «Производительность».]''
[[Image:Linus-git-googletalk.0-51-10.996.jpg|right]]

Производительность — в первую очередь не это.

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

Одна из вещей, в которой я хочу вас убедить — это
то, что слияния происходят очень-очень быстро, потому что
я хочу, чтобы люди сливали как можно раньше и чаще,
потому что тогда это легче делать.
Если вы объединяете изменения каждый день, вы никогда не попадете
в неожиданную ситуацию с тяжелыми трудноразрешимыми конфликтами.

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

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

Жестко сказано, правда?

Наверняка несколько из них сейчас в этой комнате.

Ну вы и тупые!

''[смех]''

Например, Subversion очень шумно хвалится, что
они исправили CVS, сделав ветвления дешевыми.
Это есть на их главной странице, где они вроде говорят,
что ветвление в SVN требует ''O(1)'' операций,
и что можно сделать дешевых ветвей столько, сколько хотите.

Неважно, что ''O(1)'', мне кажется, на самом деле имеет
довольно большое ''O'', но даже если ветвление занимает микросекунду,
кого это волнует?

Вы меряете не то, что нужно.

Ветки полностью бесполезны, если Вы не объединяете их,
а CVS не может объединить вообще ничего.
Вы можете слить изменения однажды,
но тогда CVS забывает то, что вы сделали, и вы никогда не
сможете объединять снова, не получая адские конфликты.
Слияния в Subversion — полная беда.
Разработчики Subversion отчасти признают это, и у них есть некий замысел,
но эти идеи тоже фигня.

Невероятно, насколько эти люди глупы.
Они все время смотрели на проблему неверно.
Проблема-то не в ветвлении, а в слиянии!
А нормальное слияние они так за пять лет и не сделали.
Вот что грустно.

Итак, быстродействие важно, но надо смотреть в корень проблемы.

Затраты на то, чтобы сделать ветку под <tt>git</tt>,
буквально заключаются в создании 41-байтного файла.
Ну насколько это быстро, как думаете?
Не думаю, что вы даже сможете это измерить.
Вы можете, в общем, если вы используете Windows, вероятно
вы можете измерить это, потому что… [''аудитория: смех'']
но как бы то ни было, это так быстро, что реально вы
не сможете это измерить.
И это создает ветку.
Но никого это не волнует, это-то не проблема.

Единственное, что важно, это как быстро вы можете сливать изменения.
В <tt>git</tt> вы можете объединить… я сливаю изменения в 22 тысячах файлов несколько раз в день, и я недоволен,
если объединение занимает более пяти секунд,
и все эти пять секунд загружаются в основном уходят на загрузку ''diffs'', ладно, не ''diffs'',
а дельты между двумя деревьями, а само объединение занимает менее
чем полсекунды.

И я не должен думать об этом.

Вот что длится дольше чем слияние, это то, что после каждого слияния,
по умолчанию <tt>git</tt> сделает <tt>diffstat</tt>
всего, что изменилось в результате объединения, потому что
мне это важно.
Когда я вливаю чьи-то изменения, я им доверяю, но с другой стороны,
вдруг они уже забросили свои лекарства?
Так что я доверяю им, да, но будем говорить начистоту — может
они были в порядке вчера, но сегодня был не их день…
Так что для контроля я делаю <tt>diffstat</tt> и <tt>git</tt> тоже делает <tt>diffstat</tt> по умолчанию,
хотя вы конечно можете для скорости его отключить, но лучше не надо,
<tt>diffstat</tt> по-любому быстр, и обычно занимает…, ну если большое слияние,
обычно занимает секунду-другую.
Поскольку создание ''diff'' и фактически подсчет статистики о том, сколько
строк изменилось — намного более затратная операция,
чем выполнение непосредственно слияния.

Это вид быстродействия, который фактически изменяет ваш стиль работы.
Это не улучшения быстродействия тех же действий, а возможность работать
совершенно по-другому.
Вот что на самом деле означает производительность, и вот почему
вам не стоить смотреть ни на что, кроме <tt>git</tt>.

Hg (Mercurial) довольно хорош, но <tt>git</tt> лучше.

Я думаю, что у меня заканчивается время, мы посмотрим, есть ли еще …,
… о, ОК это все еще интересно.

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

Код и структуры данных очень-очень-очень просты.
Если вы посмотрите на исходный текст и поймете,
что там всего где-то 80000 строк, в основном на Cи,
ну на таком Си, на котором пишу я — большинство его не понимает,
но зато я комментирую код.

Исходный код может порой выглядеть сложным,
потому что мы очень печемся о производительности, особенно я.
Я действительно забочусь об этом, и иногда заставляю вещи работать сильно быстрее,
но при этом приходится использовать более сложные алгоритмы,
чем последовательная проверка файлов по очереди.
Когда вы делаете слияние 22 тысяч файлов, вы не хотите проверять по одному файлу,
вы хотите посмотреть все дерево сразу и сказать:
«А они же одинаковые, я не должен ничего делать».
В общем, <tt>git</tt> делает все такие штуки, и все это несколько раздувает объем кода,
ибо по-уму все это сделать непросто, но основы все же очень и очень просты.

И одна из этих основ, это аспект безопасности и надежности.

''Показывает слайд:''
[[Image:linus-git-googletalk.0-56-39.330.jpg|center]]

Когда <tt>git</tt> отслеживает ваш проект, мы сжимаем каждый блок данных,
вычисляя дельту (различия) по отношению ко всем другим блокам,
кроме того мы вычисляем SHA-1 хеш, который проверяется при
необходимости достать этот блок.

Если у вас побился диск или память, или что-то еще в этом роде — <tt>git</tt> об этом сообщит.
Это даже не вопрос. Это безусловная и безоговорочная гарантия.

У вас могут быть люди, пытающиеся навредить.
У них не выйдет.

Вам нужно точно знать 20 байтов 160-битного SHA-1 хеша от верхушки вашего дерева,
и если вы их знаете, вы сможете доверять вашему дереву сверху донизу,
всей истории целиком.
У вас может быть десять лет истории проекта с сотней тысяч файлов,
миллионами ревизий, но вы сможете доверять любой части любой ревизии.
Потому что <tt>git</tt> такой надежный, и все его основные структуры данных
очень-очень просты.

Да, мы проверяем контрольные суммы.
Но мы не считаем ''слабую'' контрольную сумму, как у некоторых UDP пакетов,
то есть 16-битную сумму всех байтов.
Мы проверяем контрольные суммы, которые считаются криптографически стойкими.

Никто не может взломать SHA-1, но дело в том, что для <tt>git</tt>,
SHA-1 это не функционал информационной безопасности,
а просто проверка целостности.
Безопасность там отдельно.

А то полно народу думают, что раз <tt>git</tt> использует SHA-1,
а SHA-1 используется во всяком криптографическом софте,
то наверно это крутая фича в безопасности.
Так вот, ничего тут нет общего с безопасностью,
это просто самый лучший хеш из имеющихся.

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

Ну то есть, есть тут некоторые основания и с криптографической стороны,
но все это только про гарантии целостности ваших данных.
Я вам гарантирую, что если вы положите ваши данные в <tt>git</tt>,
спустя пять лет, даже если вы сконвертировали их с вашего
винчестера на какой нибудь DVD, или что там будет вместо него,
вы сможете проверить ваши данные и вернуть их назад в том же состоянии,
в котором вы поместили их в систему.
Именно этого вы и должны ждать от любой системы контроля версий.

Одна из причин, по которой я так агитирую за это, состоит в том,
что у нас был случай со взломом одного из сайтов BitKeeper’а,
когда народ пытался испортить репозиторий с исходниками ядра,
а BitKeeper отловил эту попытку.
Но BitKeeper не имеет по настоящему крутого хеша,
думаю, там простейший 16-CRC код, или что-то типа этого.

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

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

Нет, ну может ваши проекты и не очень важные, но мои проекты точно важны, и поэтому
я об этом так пекусь.

Это — также одна из причин, … вернемся на секунду к концепции распределенности …,
ну, например, вы делаете ваш проект [[EnPedia:Google Code|Google code]],
где можно держать исходники в ваших репозитариях,
так вот — я бы никогда не доверил Google хранить и поддерживать мои исходники.
Извините, но вы еще не заслужили моего доверия.

Причина, по которой я предпочитаю распределенные системы,
состоит в том, что я могу держать свой исходный текст позади
трех брандмауэров на системе, которая не позволяет даже по <tt>ssh</tt> войти.
Вот здесь я не могу читать свою электронную почту, потому что моя почта
идет на мою машину и единственный путь, как я могу попасть на мою машину
— это когда я физически нахожусь в той сети.

Может я конечно и полностью свихнулся, может только слегка сдвинулся,
и я забочусь о безопасности больше, чем большинство окружающих.
Да и вообще, чтобы я дал эталонную копию репозитария исходников,
о котором я так пекусь, куда-то на сторону?
Абсурд!

Даже Гуглу не дам.
Никогда в жизни, хоть ты меня режь.

Я позволю Google держать копию репозитория, но
хочу чтобы было что-то, про что я знаю точно, что никто это не трогал.

Кстати, я не такой уж и крутой сисадмин, так что сбой на винте
для меня определенно будет проблемой, так как бэкапами я не заморачиваюсь.
Но все будет в порядке, если я смогу загрузить обратно данные из нескольких
доверенных источников. Я смогу их сравнить друг с другом, это реально просто,
я смогу сверить их хеши с теми самыми 20 байтами, о которых я очень-очень
заботился — надеюсь, в нескольких местах они останутся.

20 байтов отследить легче, чем 180 МБ.

И очень маловероятно, что побьются именно эти 20 байтов.

И если у меня есть эти 20 байтов, я могу загрузить <tt>git</tt>-репозитрий даже
из совершенно «левого» источника, и могу гарантировать, что они не сделали с ним ничего плохого.

Ваш проект [Google Code] — хостинг репозитариев для народа — крутое и благое дело,
вот только вы неправильно делаете, если используете для него Subversion.
Из-за вас люди ночами спать спокойно не будут!

Конечно, если вы делаете это для 70 … , сколько там проектов,
75 тысяч?
Большинство из них довольно мелкие и ерундовые, так что все в порядке.
Но если бы вы все сделали правильно, люди бы чувствовали себя получше.

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

== Content Management ==

Я уже немного говорил на тему «Полный целостный проект vs. Отдельные файлы»,
и что <tt>git</tt> отслеживает именно полный проект.

[[Изображение:linus-git-googletalk.1-03-18.642.jpg|framed|right| «Это гораздо больше чем случайный набор файлов»]]

Ну тут на слайде единственный пример с вызовом из командной строки,
''gitk'' — это GUI вьювер истории проекта под <tt>git</tt>,
это скрипт на tcl/tk для просмотра всей той информации, которую <tt>git</tt>
действительно хорошо показывает, а вот это пример командной строки, которую я использую как
«мейнтейнер» высшего уровня.

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

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

Этот функционал <tt>git</tt> по-настоящему уникален!
Больше никто этого не может, а эта функциональность очень важна!
Может быть, она и не так важна для отдельного разработчика,
потому что отдельный разработчик часто думает в терминах отдельных файлов,
но важно для людей, объединяющих версии проекта.
Это важно для таких как я и тех, с кем я непосредственно работаю,
потому что они практически никогда не заботятся об отдельных файлах,
а вот такие вещи для них важны.
Кто-нибудь отправляет отчеты об ошибке, которые не всегда адекватны,
но пусть вам попался довольно вменяемый отчет,
и вы можете сразу засечь — «Ага, это подсистема SCSI».

Вот командная строка (''указывает на слайд'').

Вы не можете указать точно проблемный файл, но можете сказать:
«Удали последние 15 тысяч коммитов, сделанных с прошлой недели, и он откатит
проект до 50 [коммитов]»

Это круто, и никакая другая система так не может, уверяю.

Вот поэтому вы и должны хотеть использовать именно <tt>git</tt>.
Вот к чему это сводится.
Он надежен и так безопасен, что вы можете делать то, что
остальные системы или не делают, или делают очень медленно,
и кроме того, он распределенный.

Итак, продолжим.
Полагаю, мы можем позволить ответить на еще один вопрос.
Что у нас с временем, я как-то без понятия… Ладно, давайте быстро.

[[Image:linus-git-googletalk.1-05-57.109.jpg|framed|right|…будет просто дрейф проблем с масштабируемостью…?]]

'''''Слушатель:'''''

{{question}} Итак, причина ухода с Perforce — на самом деле масштабируемость и эффективность.
Иначе люди просто продолжат ее использовать.
И может, при переходе будет просто дрейф проблем с масштабируемостью и производительностью
из одной области в другую?

'''''Линус:'''''

Ну я уже говорил, что я без понятия, как вы работаете
с Perforce, и какие с ним проблемы, но если вы перейдете на <tt>git</tt>,
вы можете быть в нем уверены, если, конечно,
вы будете использовать его в разумных пределах.
А эти пределы обычно достаточно очевидны.
У вас есть компилятор, основные исходники,
документация, ну может ваша документация разбросана как-то фрагментами,
хотя наверняка у вас есть что-то типа пользовательской документации,
может в Google не так, но во многих компаниях отдельно
идет набор документации для потребителей
и документации, сопровождающей отдельные модули и пакеты.

Так что одним из моментов использования <tt>git</tt>, о котором стоит подумать,
это как организовать разумную структуру проекта.
Git легко поддерживает здоровые проекты, вы можете без проблем держать в нем
десятки тысяч файлов, вот в Ядре, например, их 22 тысячи.
Мы тестировали на ста тысячах — и все было в порядке — <tt>git</tt> быстрей, чем что бы то ни было.

С миллионом файлов, подозреваю, другие системы, могут быть в чем-то и побыстрее.
И не хотелось бы, чтобы вы попали в такую ситуацию.
Но если вы правильно организуете проект и грамотно настроите,
<tt>git</tt> будет и быстрее и лучше, что все остальное.
Я уверен в его исключительной производительности.

Вот одна из вещей, которую мы не очень хорошо делаем,
это «CVS annotate»<ref>Команда, сообщающая по каждой строчке автора, совершившего в этой строчке последнее изменение и последнюю ревизию, в которой эта строчка менялась.</ref>.
Люди часто используют эту команду.
Я говорил, что у Perforce оно тормозит, так что вы,
вероятно, хотя и не уверен, не используете Perforc’ный «annotate».
Но пользователи CVS используют «CVS annotate»,
эту единственную операцию, которую CVS может выполнять быстрее, чем <tt>git</tt>,
потому что CVS работает «пофайлово», а <tt>git</tt> — нет.

У <tt>git</tt> есть «annotate», но фактически это будет поиск,
вы можете узнать об этом, если вы переместите функцию из одного файла в другой,
<tt>git</tt> дословно воспроизведет историю функции, даже несмотря на перемещение.
Внимание, не перемещение файла, а функцию в пределах файла
он пойдет и откопает и скажет:
«Эй! Эти две строки на самом деле пришли из
того файла 5 лет назад».

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

В других проектах у нас есть история и подлинней,
мы делали на них замеры, например, после импорта KDE и других проектов
с еще более длинной историей.
Тут бывают проблемы с производительностью, но все равно даже
с учетом таких проблем <tt>git</tt> на один-два порядка быстрее, так что
в основном беспокоиться не о чем.

И если обнаружите какую-нибудь проблему, то у нас сейчас очень-очень
классное сообщество.
В <tt>git</tt>-овом списке email-рассылок уровень «шума» очень мал,
и хотя писем там изрядное количество, это очень вменяемый мейллист.
Итак, если кто-то заинтересовался, посмотрите исходники,
но начните с просмотра архива рассылки.
У нас есть и свои флеймы, есть и бесцельные споры,
но большинство сообщений там весьма хороши.

OK? Спасибо…

[''апплодисменты'']

== Ссылки ==
<references/>

== См. также ==
* [http://video.google.com/videoplay?docid=-7724296011317502612 Mercurial Project] — Bryan O'Sullivan на Google TechTalks о распределенной системе контроля версий [http://www.selenic.com/mercurial/ Mercurial]
* [[:Категория:Статьи о Subversion|Статьи о Subversion]] — Серия переводов популярных статей известных авторов о системе управления версиями [[Subversion]].

{{replicate-from-custiswiki-to-lib}}

Линус Торвальдс о GIT на Google Talks

2009-05-30T06:06:40Z

Andrew: См. также Bryan O'Sullivan на Google TechTalks о распределенной системе контроля версий Mercurial

Continuous Integration

2009-03-23T17:32:12Z

Andrew: /* Модульное тестирование и покрытие */

= Введение =
«Continuous Integration» — это лекарство от страха. Помогает при программировании.
Dr. Zoidberg ©

Согласно [http://en.wikipedia.org/wiki/Continuous_Integration Wikipedia] термин Continuous Integration введен Мартином Фаулером (Martin Fowler) и Кентом Беком (Kent Beck). Данный термин был придуман ими для обозначения практики частой сборки (интеграции) проекта. Максимально частая сборка является логичным продолжением цепочки
итерационные сборки -> ночные сборки -> непрерывная сборка

В настоящее время Continuous Integration (непрерывная интеграция) одна из практик применяемых в семействе гибких (Agile) методологий. В подобных методологиях она удачно сочитается с другими практиками, такими как модульное(unit) тестирование, рефакторинг, стандарт кодирования. Но даже без них можно получить пользу от непрерывной интеграции.

= Основные принципы =

== Каждое изменение должно интегрироваться ==

Слово continuous в термине [[Continuous Integration]] означает «непрерывный/непрекращающийся». Это означает, что в идеале сборка вашего проекта должна идти буквально все время. Каждое изменение в системе контроля версий (например [[CVS]]) должно интегрироваться без пропусков или задержек. Организация ночных сборок — это хорошая практика, но это не continuous integration. Ведь результаты такой ночной сборки будут доступны лишь на следующий день, когда их актуальность для разработчиков уже значительно снижена. На практике довольно часто реализуют оба процесса и непрерывную интеграция и ночные сборки — более редкую интеграцию.
В очень крупных проектах это требование иногда невозможно соблюсти, но интеграция каждые сутки это предел за который не стоит уходить.
Принцип непрерывной интеграции не выполним без другого условия — «Сборка должна идти быстро».

== Быстрая сборка ==

«Сборка должна идти быстро» — точнее не более 10 минут. Если после одного небольшого коммита ваш интеграционный сервер будет уходить в 2-х часовое пыхтение на сборку, тестирование и разворачивание от этого будет мало пользы. Разработчики будут уже далеко, над решение других проблем, им будет сложно вернуться и понять причины сбоя, если таковой был. Ведь суть непрерывной интеграции в получении быстрого feedback. Вдобавок, поздний ответ с сервера может отвлечь их от другого дела.

В случае если все этапы процесса никак не удается втиснуть в приемлемые временные рамки можно разделить его на несколько частей. При каждом коммите производить лишь саму сборку и минимальный набор тестов (smoke tests), чтобы уменьшить время. А по ночам проводить полный цикл интеграции, результаты которого команда будет анализировать с утра. Но это скорее вынужденная мера, а не пример для подражания.

== Сделайте тесты ==

Тесты просто необходимо включать в continuous integration процесс, в противном случае вы не можете быть уверены в качестве и работоспособности своего проекта. Чем тестов больше, тем лучше, в разумных пределах конечно. Основными двумя ограничителями на количество тестов будет:
* время интеграции — сборка по-прежнему должна оставаться быстрой, основное тестирование можно перенести «на ночь»,
* наличие автоматизированных тестов — не все тесты требуют автоматизации, нет смысла делать автоматизированные тесты только для самих тестов, они должны быть целесообразны.

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

Именнно присутствие тестов одно из отличий интеграции от нажатия кнопки Build в вашей любимой IDE.

== Интеграция на специальной машине ==

Организовывать процесс необходимо на специально выделенной машине.
Такая машина по своей конфигурации и набору прикладных программ должна максимально соответствовать окружению в котором проект будет развернут (production enviroment). Очевидно, что полного совпадения достичь практически невозможно — маловероятно, что эксплуатироватся программа будет на машине с установленными средствами сборки, тестирования и проч. Но точное совпадение версий операционных систем (и сервис паков) необходимо.

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

= Методы =

== Continuous Integration сервер ==

Хотя в принципе практика continuous integration не требует никакого технического и программного обеспечения, гораздо удобнее, проще и дешевле наладить процесс с использованием таких средств. Такие средства называются сервера интеграции (continuous integration server)- специализированные приложения для автоматизации данного процесса.

Наиболее известный из серверов интеграции пожалуй [[CruiseControl]]. [[CruiseControl]] это сервер для интеграции приложений на java, написанный на java. Так же широко распространен его собрат (точнее портированная версия) под .NET — [[CruiseControl.NET]].

Ниже приведена схема организации такого сервера интеграции:
<graph>
digraph G{
rankdir=LR

Trigger [shape="box", style="filled", fillcolor="green", label="Trigger", URL="#Trigger"]
BuildLoop [shape="box", style="filled", fillcolor="yellow", label="Build Loop", URL="#Build_Loop"]
Report [shape="box", style="filled", fillcolor="yellow", label="Reporting App", URL="#Report"]
ExtApps [shape="box", style="filled", fillcolor="yellow", label="External Applications", URL="#Инструменты"]
Logs [shape="box", style="filled", fillcolor="yellow", label="Logs", URL="#Logs"]
Team [shape="box", style="filled", fillcolor="green", label="Team", URL="#Team"]

subgraph cluster_machine{
node [style=filled];
label = "Build Machine";
URL="#Build_Machine"

subgraph cluster_server{
node [style=filled];
BuildLoop -> Report;

label = "CI Server";
URL="#Continuous_Integration_сервер"
color=blue;
}

ExtApps->BuildLoop; /*->Logs;*/
ExtApps->Logs->Report;
color=blue;
}

Trigger->BuildLoop;
BuildLoop->ExtApps;
Report->Team;
}
</graph>

== Ручной процесс ==

Хотя решение с выделенным сервером для continuous integration кажется простым и дешевым, у него есть противники. Точнее, сторонники ручного процесса. Один из таких Джеймс Шор (James Shore) в своей статье [http://www.jamesshore.com/Blog/Continuous-Integration-on-a-Dollar-a-Day.html Continuous Integration on a Dollar a Day] пишет, как правильно организовать continuous integration процесс без специализированных приложений, вроде [[CruiseControl]]. В этой статье мы не касаемся данного вопроса.

= Процесс интеграции =

Continuous integration процесс состоит из нескольких этапов, некоторые из которых обязательны, другие нет:
* [[#Trigger|Trigger]] — обязателен
* [[#Update|Update]] — обязателен
* [[#Analyse|Analyse]] — не обязателен
* [[#Build|Build]] — а как без него?
* [[#UnitTest|UnitTest]] — крайне желателен
* [[#Deploy|Deploy]] — нужен по обстоятельствам
* [[#Test|Test]] — не обязателен, но крайне желателен
* [[#Archive|Archive]] — желателен
* [[#Report|Report]] — обязателен

== Trigger ==

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

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

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

== Update ==

На данном этапе CI сервер делает update своей локальной копии исходного кода проекта. В процессе update выясняются изменения в коде (и не только) произошедшие с последненй интеграции. Выяснение изменений необходимо для того, чтобы в случае сбоя можно было легко выяснить причину и найти ответственного.

== Analyse ==

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

Данный этап является необязательным для процесса continuous integration, но в случае его наличия можно получить дополнительный преимущества от введения практики в виде метрик по коду. Данный этап подразумевает не только получение статических характеристик кода, но и их включение в отчеты создаваемые сервером интеграции (о отчетах смотрите [[#Report|здесь]]).

== Build ==

Один из основных этапов процесса это сборка проекта. Здесь происходит компиляция (трансляция) исходных кодов в исполнимые файлы или какой-то другой результат. Поскольку сервер интеграции представляет собой специально выделенную машину (смотрите [[#Интеграция_на_специальной_машине|здесь]]) со строго определенной конфигурацией, результат только этой сборки можно считать конечным. Больше никаких «Проект собирается на моей машине!». Есть только одно место, где проект может собираться — это интеграционный сервер.

Естественно сборка является обязательным этапом интеграции.

== UnitTest ==

В методологии Extreme Programming модульное (unit) тестирование является неотъемлемой частью разработки приложения. Модульные тесты изначально автоматизированы, их включение в процесс интеграции крайне желательно. Поскольку часто у разработчиков нет времени или желания запускать такие тесты до того как изменения отправлены в систему контроля версий, дополнительное их исполнение никогда не будет лишним.
Дополнительную информацию можно извлечь, измеряя покрытие модульных тестов. Эта метрика поможет лучше контролировать качество выпускаемого продукта.

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

== Deploy ==

После того как мы убедились в некоторой работоспособности проекта — он собирается (этап [[#Build|Build]]) и все модульные тесты проходят ([[#UnitTest|UnitTest]]) проект необходимо «развернуть». В случае веб-приложения это выкладывание на веб-сервер (сервер приложений) и запуск. Для GUI приложений это (пере)установка в системе.

Этап развертывание должен проходить как можно более «чисто», подробнее смотрите [[#Интеграция_на_специальной_машине|здесь]]. При этом для последующего тестирования часто необходимо привести приложение в некое «стандартное» состояние:
* «залить» дамп базы
* настроить в стандартном режиме
* убрать следы предыдущей деятельности приложения

== Test ==

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

После прохождения регрессионных тестов можно считать, что интеграция прошла успешно и в проект не внесено правок, которые могут привести к его неработоспособности (здесь все зависит от вашего набора тестов модульных и функциональных). В противном случае интеграция не успешна — код содержит ошибки и требуется его исправление/доработка.

Тестирование это один из «фатальных» этапов процесса, ошибка на котором означает сбой сборки. Всего есть несколько таких «фатальных» этапов:
* [[#Build|Build]] — проект не собирается
* [[#UnitTest|UnitTest]] — модульные тест не прошли или покрытие упало ниже заданного уровня
* [[#Test|Test]] — регрессионные тесты не прошли или покрытие упало ниже заданного уровня

Иногда к ним присоединяют этап [[#Analyse|Analyse]] — если в коде обнаружено несоответствие стандартам кодирования, то это является ошибкой.

== Archive ==

После того как достигнута максимальная уверенность в качестве исходного кода необходимо сохранить его. Это можно сделать, например, посредством меток в системе контроля версий. Так же необходимо сохранить бинарные файлы проекта. Они могут понадобиться, если нужно будет воспроизвести ошибку в конкретной версии и для ручного тестирования.

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

== Report ==

В конце идет важный этап генерации и публикации отчетов. Отчеты включают в себя следующее:
* причина сборки — например изменения в репозитории
* изменения в исходных кодах — здесь возможны два варианта изменения от последней сборки или от последней успешной сборки
* отчеты по статическому анализу кода — все результаты какие есть
* лог сборки
* лог модульных тестов — какие тесты прошли и, что важнее, какие не прошли
* лог регрессионных тестов — аналогично модульным тестам
* статистика сборок проекта:
** общее число удачных/провальных сборок
** распределение удачных/провальных сборок во времени
** статистика результатов статического анализа кода
* все другие метрики используемые и собираемые в проекте — это поможет менеджеру проекта видеть все и сразу

Механизм публикации отчета может быть разный и даже не один. Это может быть IRC или jabber бот, рассылка по электронной почте, публикация на web или ftp сервере, специализированные клиенты позволяющие узнать статус сборки.

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

Для правильной организации данного этапа важно понимать кого и как необходимо оповещать о результатах интеграции. Здесь надо выбрать между двумя крайностями — оповещать всегда или никогда. Примерное решение этой задачи будет таким:
* разработчики — минимум при сбое интеграции, в противном случае, как разработчик узнает, что внесенные им изменения сломали код? Конечно, можно оповещать и всегда, это зависит от частоты сборок.
* тестировщики — если они входят в команду, то оповещать тогда же, когда и разработчиков, ведь иногда ошибки могут быть и в тестах. Если практикуется независимое тестирование вообще не оповещать их или оповещать при окончании интеграции.
* менеджер проекта — сугубо по желанию

= Профиты =

Так какую пользу можно получить о внедрения непрерывной интеграции в своем проекте?

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

Больше никаких «Это работает на моей машине!». Если что-то не работает на сборочном сервере — значит оно не работает вообще. Аргументы программиста, что у него все работает в данном случае не помогут. Сервер интеграции становиться судьей в таких вопросах и этот судья беспристрастен.

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

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

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

= Continuous Improvement =

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

= Ссылки =

== Публикации ==

* [http://www.martinfowler.com/articles/continuousIntegration.html Continuous Integration] — статья Мартина Фаулера (Martin Fowler) по Continuous Integration
* [http://www.jamesshore.com/Blog/Continuous-Integration-on-a-Dollar-a-Day.html Continuous Integration on a Dollar a Day] — статья Джеймса Шора (James Shore) о ручном методе интеграции
* [http://blogs.msdn.com/mswanson/articles/169058.aspx Automated Continuous Integration and the Ambient Orb] — статья Майка Свонсона (Mike Swanson)
* [http://www.custis.ru/docs/publishing/secr-2008/article-ci.pdf «Введение в непрерывную интеграцию или каша из топора»] — статья Андрея Сатарина, представленная на конференции [http://secr.ru/ SEC(R) 2008]. Так же доступна [http://www.custis.ru/docs/publishing/secr-2008/talk-ci.pdf презентация] и [http://www.custis.ru/docs/publishing/secr-2008/talk-ci-handout.pdf презентация-handout].
* [http://c2.com/cgi/wiki?ContinuousIntegration c2.com] — статья по Continuous Integration в wiki на c2.com
* [http://en.wikipedia.org/wiki/Continuous_Integration en.wikipedia.org] — статья по Continuous Integration в Wikipedia
* [http://ru.wikipedia.org/wiki/Непрерывная_интеграция ru.wikipedia.org] — статья по непрерывной интеграции в Википедии

* [http://www.pragprog.com/titles/auto/pragmatic-project-automation www.pragprog.com] — книга «Pragmatic Project Automation». [http://media.pragprog.com/titles/auto/scheduled.pdf Глава], которая посвящена непрерывной интеграции доступна бесплатно.
* [http://www.amazon.com/Continuous-Integration-Improving-Addison-Wesley-Signature/dp/0321336380/ref=sr_1_1?ie=UTF8&s=books&qid=1206124954&sr=8-1 www.amazon.com] — книга Пола Дюваля (Paul Duvall) о непрерывной интеграции, получившая Jolt Award в 2008 году
* [http://www.ozon.ru/context/detail/id/3851770/ www.ozon.ru] — эта же книга изданная на русском языке

== Инструменты ==

=== Сервера интеграции ===
* [http://cruisecontrol.sourceforge.net CruiseControl] — сервер интеграции для Java (см. так же [[CruiseControl]]).
* [http://studio.thoughtworks.com/cruise-continuous-integration ThoughtWorks Cruise] — коммерческий сервер интеграции от компании ThoughtWorks (есть бесплатная версия).
* [http://ccnet.sourceforge.net CruiseControl.NET] — сервер интеграции для .NET (см. так же [[CruiseControl.NET]])
* [http://cruisecontrolrb.thoughtworks.com CruiseControl.rb] — сервер интеграции для Ruby.
* [http://hudson.dev.java.net Hudson] — open-source сервер интеграции, создан как альтернатива [[CruiseControl]]. Функциональность расширяется плагинами.
* [http://bitten.edgewall.org Bitten] — open-source сервер интеграции написанный на [[Python]], интегрируется с [[Trac]].
* [http://www.jetbrains.com/teamcity/index.html TeamCity] — коммерческий сервер интеграции от компаниии JetBrains для java и .NET (есть бесплатная версия).

=== Инструменты сборки ===
* [http://ant.apache.org Ant] — средство сборки для Java
* [http://maven.apache.org Maven] — средство сборки для Java
* [http://nant.sourceforge.net/ NAnt] — аналог Ant под .NET

=== Статический анализ ===
* [http://pmd.sourceforge.net PMD] — анализ кода Java
* [http://findbugs.sourceforge.net Findbugs] — анализ кода на типичные ошибки
* [http://www.redhillconsulting.com.au/products/simian/ Simian] — поиск повторов (copу+paste) в коде Java
* [http://www.gotdotnet.com/team/fxcop/ FXCop] — анализ кода .NET
* [http://qalab.sourceforge.net/index.html QALab] — объединение логов нескольких инструментов анализа кода, сбор статистики
* [http://www.panopticode.org/ Panopticode] — объединение логов нескольких инструментов анализа кода для Java, графическое представление результатов

=== Модульное тестирование и покрытие ===
* [http://junit.org JUnit] — де-факто стандарт модульного тестирования Java
* [http://testng.org TestNG] — инструмент нового поколения для модульного тестирования Java
* [http://www.nunit.org/ NUnit] — модульные тесты для приложений .NET
* [http://cobertura.sourceforge.net Cobertura] — измерение покрытия кода модульными тестами для Java
* [http://www.atlassian.com/software/clover/ Clover] — анализ покрытия кода тестами для Java
* [http://www.cenqua.com/clovernet/ Clover.NET] — анализ покрытия кода тестами под .NET

== Юмор ==
* [http://www.youtube.com/watch?v=XV5fViOoV_ «Every build you brake»] — песня в исполнении Роя Ошерова (Roy Osherove)
* [http://www.youtube.com/watch?v=Azl4nqLn4-Y «Hitler’s nightly build fails»] — пародия о неудавшейся ночной сборке

[[Категория:Программирование]]
[[Категория:Тестирование программного обеспечения]]
{{replicate-from-custiswiki-to-lib}}

CruiseControl

2008-09-12T07:05:10Z

Andrew: Отмена правки № 9909 участника Andrew (обсуждение)

= Введение =

CruiseControl — платформа (серверное приложение) для организации [[Continuous Integration|непрерывной сборки]] написанная полностью на Java.
* Сайт http://cruisecontrol.sourceforge.net/
* Лицензия — открытая, BSD-подобная

CruiseControl используется для организации [[Continuous Integration|непрерывной сборки]] проектов, без участия людей (кроме начального этапа конфигурирования). После конфигурирования сервер собирает и тестирует проект при помощи различных внешний инструментов при каждом изменении в репозитории проекта. При помощи него можно сразу отловить новые ошибки возникающии при интеграции кода разных разработчиков и постоянно проверять старые при помощи автоматических тестов.

== Зачем это надо ==

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

Если к сборке добавить еще и автоматичесикие тесты, то всегда можно быть уверенным в том, что текущая версия в CVS и работает как надо. Всю сборку и тестирование можно проводить при каждом commit`е не тратя никаких усилий (все сам сделает сервер), а возникающие ошибки и несовместимости решать сразу быстро и эффективно.
Более подробные примеры использования можно найти в первых двух [[#Ссылки|ссылках]].

== Возможности ==

Сервер CruiseControl имеет следующие возможности:
* работает по расписанию или
* следит за изменениями:
** в репозитории [[CVS]] и многих других систем контроля версий
** в файлах и директориях
** в сборке других проектов
* сам вытащит новую версию из [[CVS]](и других)
* соберет используя Ant, Maven, скрипт
* опубликует результаты:
** в зависамости от результата сборки
** на web-сервере входящем в комплект
** разошлет почту
** выполнит скрипт (shell, bat)
** выполнит скрипт Ant
** много других способов
* конфигурируется одним XML файлом — его тоже можно хранить под [[CVS]]

== Конфигурационный файл ==

Это XML файл в котором описано как, когда и что должен делать CruiseControl.
Самый верхний уровень это проект — все остальные настройки в нем. Проектов может быть много и они могут собираться или не собираться в зависимости друг от друга.

Внутри файла:
* <property> — переменные или файл переменных
* <bootstrappers> — то, что выполняется до сборки
* <listeners> — в основном для отображения статуса на web-сервере
* <modificationset> — за какими изменениями следить
* <schedule> — собственно расписание сборки (см. [[#Цикл сборки]])
* <publishers> — публикация результатов

== Цикл сборки ==

В цикл сборки запускается процесс-демон, который периодически выполняет действия описанные в конфигурационном файле в элементе <schedule>. Собирать проект можно:
* скриптом
* Maven 1 или Maven 2
* Ant
* NAnt
Но за один раз запускается только один сборщик, а не все подряд как этого иногда хочется(см. [[#Проблемы/решения]]).
Сборщик запускается только если были обнаружены изменения описанные в <modificationset>, перед сборкой запускается <bootstrappers>.

== Публикация результатов ==

Публикация результатов — важная часть процесса непрерывной интеграции, это единственный способ CruiseControl сообщить вам, что все хорошо/плохо. В CruiseControl есть много разных способов опубликовать результаты. Основной из них web-сервер на котором показаны результаты всех билдов и можно посмотреть их логи, для публикации на нем ничего делать не надо. В принципе от web-сервера можно отказаться, не запускать его и использовать только e-mail оповещение.
Еще можно использовать другие методы публикации:
* скрипт Ant
* скрипт
* выкладывание артефактов на web-сервере
* e-mail
* публикация статуса сборки — для последующего за ним слежения с сервера
Метод(-ы) публикации настраивается внутри элемента <publishers>.

= Проблемы/решения =

* закладка с метриками не работает под Linux если нет доступа к графическому дисплею(X-консоли)
запускать CruiseControl из-под Х-консоли и блокировать консоль
* задокументированная особенность: за раз выполняется только один билдер т. е. для такой конфигурации:
<schedule interval="${cc.interval}">
<exec command="sh" args="${mvn.before}"/>
<maven2
mvnscript="${mvn.script}"
pomfile="${mvn.file}"
goal="${mvn.goal}"
/>
</schedule>

Будет выполнен ЛИБО exec ЛИБО maven2, что плохо, приходится все сливать в один скрипт.
Но есть и свои преимущества можно сделать разные билды(например обычный и с тестами) и выполнять с разной частотой.

В последних версиях для удобства есть метод сборки <composite>, в который можно включать другие методы сборки. В этом случае все они будут выполнены последовательно, если не произойдет сбоя.

= Ссылки =
* [http://en.wikipedia.org/wiki/CruiseControl CruiseControl в Wikipedia]
* [http://cruisecontrol.sourceforge.net Cтраница проекта CruiseControl]

[[Category:Программирование]]
[[Category:Тестирование программного обеспечения]]

{{replicate-from-custiswiki-to-lib}}

CruiseControl

2008-09-10T18:27:16Z

Andrew: /* Ссылки */

= Введение =

CruiseControl — платформа (серверное приложение) для организации [[Continuous Integration|непрерывной сборки]] написанная полностью на Java.
* Сайт http://cruisecontrol.sourceforge.net/
* Лицензия — открытая, BSD-подобная

CruiseControl используется для организации [[Continuous Integration|непрерывной сборки]] проектов, без участия людей (кроме начального этапа конфигурирования). После конфигурирования сервер собирает и тестирует проект при помощи различных внешний инструментов при каждом изменении в репозитории проекта. При помощи него можно сразу отловить новые ошибки возникающии при интеграции кода разных разработчиков и постоянно проверять старые при помощи автоматических тестов.

== Зачем это надо ==

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

Если к сборке добавить еще и автоматичесикие тесты, то всегда можно быть уверенным в том, что текущая версия в CVS и работает как надо. Всю сборку и тестирование можно проводить при каждом commit`е не тратя никаких усилий (все сам сделает сервер), а возникающие ошибки и несовместимости решать сразу быстро и эффективно.
Более подробные примеры использования можно найти в первых двух [[#Ссылки|ссылках]].

== Возможности ==

Сервер CruiseControl имеет следующие возможности:
* работает по расписанию или
* следит за изменениями:
** в репозитории [[CVS]] и многих других систем контроля версий
** в файлах и директориях
** в сборке других проектов
* сам вытащит новую версию из [[CVS]](и других)
* соберет используя Ant, Maven, скрипт
* опубликует результаты:
** в зависамости от результата сборки
** на web-сервере входящем в комплект
** разошлет почту
** выполнит скрипт (shell, bat)
** выполнит скрипт Ant
** много других способов
* конфигурируется одним XML файлом — его тоже можно хранить под [[CVS]]

== Конфигурационный файл ==

Это XML файл в котором описано как, когда и что должен делать CruiseControl.
Самый верхний уровень это проект — все остальные настройки в нем. Проектов может быть много и они могут собираться или не собираться в зависимости друг от друга.

Внутри файла:
* <property> — переменные или файл переменных
* <bootstrappers> — то, что выполняется до сборки
* <listeners> — в основном для отображения статуса на web-сервере
* <modificationset> — за какими изменениями следить
* <schedule> — собственно расписание сборки (см. [[#Цикл сборки]])
* <publishers> — публикация результатов

== Цикл сборки ==

В цикл сборки запускается процесс-демон, который периодически выполняет действия описанные в конфигурационном файле в элементе <schedule>. Собирать проект можно:
* скриптом
* Maven 1 или Maven 2
* Ant
* NAnt
Но за один раз запускается только один сборщик, а не все подряд как этого иногда хочется(см. [[#Проблемы/решения]]).
Сборщик запускается только если были обнаружены изменения описанные в <modificationset>, перед сборкой запускается <bootstrappers>.

== Публикация результатов ==

Публикация результатов — важная часть процесса непрерывной интеграции, это единственный способ CruiseControl сообщить вам, что все хорошо/плохо. В CruiseControl есть много разных способов опубликовать результаты. Основной из них web-сервер на котором показаны результаты всех билдов и можно посмотреть их логи, для публикации на нем ничего делать не надо. В принципе от web-сервера можно отказаться, не запускать его и использовать только e-mail оповещение.
Еще можно использовать другие методы публикации:
* скрипт Ant
* скрипт
* выкладывание артефактов на web-сервере
* e-mail
* публикация статуса сборки — для последующего за ним слежения с сервера
Метод(-ы) публикации настраивается внутри элемента <publishers>.

= Проблемы/решения =

* закладка с метриками не работает под Linux если нет доступа к графическому дисплею(X-консоли)
запускать CruiseControl из-под Х-консоли и блокировать консоль
* задокументированная особенность: за раз выполняется только один билдер т. е. для такой конфигурации:
<schedule interval="${cc.interval}">
<exec command="sh" args="${mvn.before}"/>
<maven2
mvnscript="${mvn.script}"
pomfile="${mvn.file}"
goal="${mvn.goal}"
/>
</schedule>

Будет выполнен ЛИБО exec ЛИБО maven2, что плохо, приходится все сливать в один скрипт.
Но есть и свои преимущества можно сделать разные билды(например обычный и с тестами) и выполнять с разной частотой.

В последних версиях для удобства есть метод сборки <composite>, в который можно включать другие методы сборки. В этом случае все они будут выполнены последовательно, если не произойдет сбоя.

= Ссылки =
* {{Link-to-wikipedia}}
* [http://cruisecontrol.sourceforge.net Cтраница проекта CruiseControl]

[[Category:Программирование]]
[[Category:Тестирование программного обеспечения]]

{{replicate-from-custiswiki-to-lib}}

Шаблон:Replicate-from-custiswiki-to-all

2008-09-09T17:41:34Z

Andrew:

Шаблон:Replicate-from-custiswiki-to-all

2008-09-09T17:41:03Z

Andrew: Новая: .

Subversion’s Future?

2008-09-06T07:23:03Z

Andrew:

<blockquote>
Перевод статьи [http://blog.red-bean.com/sussman/?p=90 {{PAGENAME}}] («Что ждет Subversion?») выполнен сообществом компании [http://www.custis.ru «Заказные ИнформСистемы»].
</blockquote>

Согласно статистике '''Google Analytics''', один из самых просматриваемых постов в моем блоге — это тот, который я написал годы назад — «[[the Risks of Distributed Version Control|Риски распределенного управления версиями]]».
Там полно сердитых комментариев о том, насколько я неправ.
Думаю, надо дополнить тот пост новостями и свежими идеями.

Итак, должен сказать, после некоторого времени использования [[RuPedia:Mercurial|Mercurial]],
я думаю, что распределенное управление версиями — штука весьма изящная.

Пока идет тестирование последней предрелизной 1.5 версии [[Subversion]],
в которой уже будут ограниченные возможности отслеживания слияний,
в коллективе разработчиков Subversion присутствует некая неясность, каким же все-таки будет его будущее.
Системы [[RuPedia:Mercurial|Mercurial]] и [[RuPedia:Git|Git]] сейчас повсюду, и постоянно становятся все более популярными, особенно среди «20%» — разработчиков-новаторов.
Какая роль у Subversion — «лучшей из лучших» централизованных систем контроля версий — в мире, где все потихоньку двигается в сторону использования децентрализованных систем?

[[Subversion]] четко выполнила задачу, которую мы поставили в 2000-м — «заменить [[CVS]].
Но останавливаться нельзя — если у [[Subversion]] не будет четких планов на будущее, то она будет заменена чем-то лучшим.
Это могут быть Mercurial или Git, а может — чем-то еще.
В идеале Subversion должна заменить себя сама. :-)

Итак, что бы мы заложили в «Subversion 2.0», если бы нам выпала честь его проектировать?
На прошлой неделе один из наших разработчиков написал изящный e-mail, где очень хорошо обобщил возможную новую миссию. Это нужно видеть — вот неплохая аннотация:

----

Сейчас я бы почти наверняка не выбрал Subversion для небольшого нового open-source проекта. [...]
Значит ли это, что <tt>Subversion</tt> мертва?
Что нам пора сменить корабль, написать новый GUI для Git и добиться
чтобы все это работало под Windows?
Нет. Централизованный контроль версий все еще хорош для некоторых вещей.
*Работа над огромными проектами, где помещение всей ''рабочей версии'' исходного кода на все машины неосуществимо, уже не говоря о всей истории (однако здесь атомарные транзакции через произвольные части проекта все же требуется).
*Механизм авторизации по чтению! Клиент-серверная модель — лучшее решение, если Вы планируете не позволять давать всем все данные (Несомненно, есть теоретические пути осуществить авторизацию по чтению на распределенных системах, но это не очень-то и просто.)
Итак, что делать?
Проект Subversion больше не должен тратить время на попытки улучшения применимости для небольших
открытых проектов.
Subversion уже подходит для этой задачи, и у других систем есть больший потенциал, чем она.
Мы должны сфокусировать внимание на задаче представления Subversion как лучшего средства для организаций,
чьим пользователям необходимо нетривиально взаимодействовать с репозиториями. [...]
Я общался с другими разработчиками, и мы пришли к некоторым схожим личным
заключениям по поводу будущего Subversion.

Во-первых, мы думаем, что это, вероятно, «последняя» централизованная
система, написанная в «мире открытого кода» — и представляет
«заключительную черту» для этой модели огранизации кода.

Она будет продолжать использоваться в течение многих лет,
причем в корпоративном мире — с громандной популярностью,
пока не проиграет (окончательно) распределенным системам в мире open-source.

У всех нас, погруженных в «open-source», действительно несколько искаженное представление о реальности.
Нам кажется, что «все переключаются на ''Git''»
но когда вы смотрите на график публичных (т.е. общедоступных, не частных)
серверов Subversion под Apache, обнаруженных в Инете,
видно, что Subversion никоим образом не «исчезает».

Как раз наоборот: его применение в корпоративном мире все еще растет квадратично, без малейших признаков замедления.
Все это происходит независимо от новаторов-опенсорсщиков,
теряющих интерес к Subversion.

Subversion может, в конце концов, стать полноценно «корпоративным» open-source проектом,
(то есть, вся разработка будет финансироваться корпорациями-пользователями Subversion),
но это прекрасный выход для зрелого программного обеспечения.

----

{{replicate-from-custiswiki-to-lib}}
[[category:Статьи о Subversion]]

Continuous Integration

2008-08-26T18:35:56Z

Andrew: /* Введение */

= Введение =
«Continuous Integration» — это лекарство от страха. Помогает при программировании.
Dr. Zoidberg ©

Согласно [http://en.wikipedia.org/wiki/Continuous_Integration Wikipedia] термин Continuous Integration введен Мартином Фаулером (Martin Fowler) и Кентом Беком (Kent Beck). Данный термин был придуман ими для обозначения практики частой сборки (интеграции) проекта. Максимально частая сборка является логичным продолжением цепочки
редкие сборки под релизы->ночные сборки->непрерывные сборки

В настоящее время Continuous Integration (непрерывная интеграция) одна из практик применяемых в семействе гибких (Agile) методологий. В подобных методологиях она удачно сочитается с другими практиками, такими как модульное(unit) тестирование, рефакторинг, стандарт кодирования. Но даже без них можно получить пользу от непрерывной интеграции.

= Основные принципы =

== Каждое изменение должно интегрироваться ==

Слово continuous в термине [[Continuous Integration]] означает «непрерывный/непрекращающийся». Это означает, что в идеале сборка вашего проекта должна идти буквально все время. Каждое изменение в системе контроля версий (например [[CVS]]) должно интегрироваться без пропусков или задержек. Организация ночных сборок — это хорошая практика, но это не continuous integration. Ведь результаты такой ночной сборки будут доступны лишь на следующий день, когда их актуальность для разработчиков уже значительно снижена. На практике довольно часто реализуют оба процесса и непрерывную интеграция и ночные сборки — более редкую интеграцию.
В очень крупных проектах это требование иногда невозможно соблюсти, но интеграция каждые сутки это предел за который не стоит уходить.
Принцип непрерывной интеграции не выполним без другого условия — «Сборка должна идти быстро».

== Быстрая сборка ==

«Сборка должна идти быстро» — точнее не более 10 минут. Если после одного небольшого коммита ваш интеграционный сервер будет уходить в 2-х часовое пыхтение на сборку, тестирование и разворачивание от этого будет мало пользы. Разработчики будут уже далеко, над решение других проблем, им будет сложно вернуться и понять причины сбоя, если таковой был. Ведь суть непрерывной интеграции в получении быстрого feedback. Вдобавок, поздний ответ с сервера может отвлечь их от другого дела.

В случае если все этапы процесса никак не удается втиснуть в приемлемые временные рамки можно разделить его на несколько частей. При каждом коммите производить лишь саму сборку и минимальный набор тестов (smoke tests), чтобы уменьшить время. А по ночам проводить полный цикл интеграции, результаты которого команда будет анализировать с утра. Но это скорее вынужденная мера, а не пример для подражания.

== Сделайте тесты ==

Тесты просто необходимо включать в continuous integration процесс, в противном случае вы не можете быть уверены в качестве и работоспособности своего проекта. Чем тестов больше, тем лучше, в разумных пределах конечно. Основными двумя ограничителями на количество тестов будет:
* время интеграции — сборка по-прежнему должна оставаться быстрой, основное тестирование можно перенести «на ночь»,
* наличие автоматизированных тестов — не все тесты требуют автоматизации, нет смысла делать автоматизированные тесты только для самих тестов, они должны быть целесообразны.

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

Именнно присутствие тестов одно из отличий интеграции от нажатия кнопки Build в вашей любимой IDE.

== Интеграция на специальной машине ==

Организовывать процесс необходимо на специально выделенной машине.
Такая машина по своей конфигурации и набору прикладных программ должна максимально соответствовать окружению в котором проект будет развернут (production enviroment). Очевидно, что полного совпадения достичь практически невозможно — маловероятно, что эксплуатироватся программа будет на машине с установленными средствами сборки, тестирования и проч. Но точное совпадение версий операционных систем (и сервис паков) необходимо.

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

= Методы =

== Continuous Integration сервер ==

Хотя в принципе практика continuous integration не требует никакого технического и программного обеспечения, гораздо удобнее, проще и дешевле наладить процесс с использованием таких средств. Такие средства называются сервера интеграции (continuous integration server)- специализированные приложения для автоматизации данного процесса.

Наиболее известный из серверов интеграции пожалуй [[CruiseControl]]. [[CruiseControl]] это сервер для интеграции приложений на java, написанный на java. Так же широко распространен его собрат (точнее портированная версия) под .NET — [[CruiseControl.NET]].

Ниже приведена схема организации такого сервера интеграции:
<graph>
digraph G{
rankdir=LR

Trigger [shape="box", style="filled", fillcolor="green", label="Trigger", URL="#Trigger"]
BuildLoop [shape="box", style="filled", fillcolor="yellow", label="Build Loop", URL="#Build_Loop"]
Report [shape="box", style="filled", fillcolor="yellow", label="Reporting App", URL="#Report"]
ExtApps [shape="box", style="filled", fillcolor="yellow", label="External Applications", URL="#Инструменты"]
Logs [shape="box", style="filled", fillcolor="yellow", label="Logs", URL="#Logs"]
Team [shape="box", style="filled", fillcolor="green", label="Team", URL="#Team"]

subgraph cluster_machine{
node [style=filled];
label = "Build Machine";
URL="#Build_Machine"

subgraph cluster_server{
node [style=filled];
BuildLoop -> Report;

label = "CI Server";
URL="#Continuous_Integration_сервер"
color=blue;
}

ExtApps->BuildLoop; /*->Logs;*/
ExtApps->Logs->Report;
color=blue;
}

Trigger->BuildLoop;
BuildLoop->ExtApps;
Report->Team;
}
</graph>

== Ручной процесс ==

Хотя решение с выделенным сервером для continuous integration кажется простым и дешевым, у него есть противники. Точнее, сторонники ручного процесса. Один из таких Джеймс Шор (James Shore) в своей статье [http://www.jamesshore.com/Blog/Continuous-Integration-on-a-Dollar-a-Day.html Continuous Integration on a Dollar a Day] пишет, как правильно организовать continuous integration процесс без специализированных приложений, вроде [[CruiseControl]]. В этой статье мы не касаемся данного вопроса.

= Процесс интеграции =

Continuous integration процесс состоит из нескольких этапов, некоторые из которых обязательны, другие нет:
* [[#Trigger|Trigger]] — обязателен
* [[#Update|Update]] — обязателен
* [[#Analyse|Analyse]] — не обязателен
* [[#Build|Build]] — а как без него?
* [[#UnitTest|UnitTest]] — крайне желателен
* [[#Deploy|Deploy]] — нужен по обстоятельствам
* [[#Test|Test]] — не обязателен, но крайне желателен
* [[#Archive|Archive]] — желателен
* [[#Report|Report]] — обязателен

== Trigger ==

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

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

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

== Update ==

На данном этапе CI сервер делает update своей локальной копии исходного кода проекта. В процессе update выясняются изменения в коде (и не только) произошедшие с последненй интеграции. Выяснение изменений необходимо для того, чтобы в случае сбоя можно было легко выяснить причину и найти ответственного.

== Analyse ==

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

Данный этап является необязательным для процесса continuous integration, но в случае его наличия можно получить дополнительный преимущества от введения практики в виде метрик по коду. Данный этап подразумевает не только получение статических характеристик кода, но и их включение в отчеты создаваемые сервером интеграции (о отчетах смотрите [[#Report|здесь]]).

== Build ==

Один из основных этапов процесса это сборка проекта. Здесь происходит компиляция (трансляция) исходных кодов в исполнимые файлы или какой-то другой результат. Поскольку сервер интеграции представляет собой специально выделенную машину (смотрите [[#Интеграция_на_специальной_машине|здесь]]) со строго определенной конфигурацией, результат только этой сборки можно считать конечным. Больше никаких «Проект собирается на моей машине!». Есть только одно место, где проект может собираться — это интеграционный сервер.

Естественно сборка является обязательным этапом интеграции.

== UnitTest ==

В методологии Extreme Programming модульное (unit) тестирование является неотъемлемой частью разработки приложения. Модульные тесты изначально автоматизированы, их включение в процесс интеграции крайне желательно. Поскольку часто у разработчиков нет времени или желания запускать такие тесты до того как изменения отправлены в систему контроля версий, дополнительное их исполнение никогда не будет лишним.
Дополнительную информацию можно извлечь, измеряя покрытие модульных тестов. Эта метрика поможет лучше контролировать качество выпускаемого продукта.

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

== Deploy ==

После того как мы убедились в некоторой работоспособности проекта — он собирается (этап [[#Build|Build]]) и все модульные тесты проходят ([[#UnitTest|UnitTest]]) проект необходимо «развернуть». В случае веб-приложения это выкладывание на веб-сервер (сервер приложений) и запуск. Для GUI приложений это (пере)установка в системе.

Этап развертывание должен проходить как можно более «чисто», подробнее смотрите [[#Интеграция_на_специальной_машине|здесь]]. При этом для последующего тестирования часто необходимо привести приложение в некое «стандартное» состояние:
* «залить» дамп базы
* настроить в стандартном режиме
* убрать следы предыдущей деятельности приложения

== Test ==

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

После прохождения регрессионных тестов можно считать, что интеграция прошла успешно и в проект не внесено правок, которые могут привести к его неработоспособности (здесь все зависит от вашего набора тестов модульных и функциональных). В противном случае интеграция не успешна — код содержит ошибки и требуется его исправление/доработка.

Тестирование это один из «фатальных» этапов процесса, ошибка на котором означает сбой сборки. Всего есть несколько таких «фатальных» этапов:
* [[#Build|Build]] — проект не собирается
* [[#UnitTest|UnitTest]] — модульные тест не прошли или покрытие упало ниже заданного уровня
* [[#Test|Test]] — регрессионные тесты не прошли или покрытие упало ниже заданного уровня

Иногда к ним присоединяют этап [[#Analyse|Analyse]] — если в коде обнаружено несоответствие стандартам кодирования, то это является ошибкой.

== Archive ==

После того как достигнута максимальная уверенность в качестве исходного кода необходимо сохранить его. Это можно сделать, например, посредством меток в системе контроля версий. Так же необходимо сохранить бинарные файлы проекта. Они могут понадобиться, если нужно будет воспроизвести ошибку в конкретной версии и для ручного тестирования.

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

== Report ==

В конце идет важный этап генерации и публикации отчетов. Отчеты включают в себя следующее:
* причина сборки — например изменения в репозитории
* изменения в исходных кодах — здесь возможны два варианта изменения от последней сборки или от последней успешной сборки
* отчеты по статическому анализу кода — все результаты какие есть
* лог сборки
* лог модульных тестов — какие тесты прошли и, что важнее, какие не прошли
* лог регрессионных тестов — аналогично модульным тестам
* статистика сборок проекта:
** общее число удачных/провальных сборок
** распределение удачных/провальных сборок во времени
** статистика результатов статического анализа кода
* все другие метрики используемые и собираемые в проекте — это поможет менеджеру проекта видеть все и сразу

Механизм публикации отчета может быть разный и даже не один. Это может быть IRC или jabber бот, рассылка по электронной почте, публикация на web или ftp сервере, специализированные клиенты позволяющие узнать статус сборки.

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

Для правильной организации данного этапа важно понимать кого и как необходимо оповещать о результатах интеграции. Здесь надо выбрать между двумя крайностями — оповещать всегда или никогда. Примерное решение этой задачи будет таким:
* разработчики — минимум при сбое интеграции, в противном случае, как разработчик узнает, что внесенные им изменения сломали код? Конечно, можно оповещать и всегда, это зависит от частоты сборок.
* тестировщики — если они входят в команду, то оповещать тогда же, когда и разработчиков, ведь иногда ошибки могут быть и в тестах. Если практикуется независимое тестирование вообще не оповещать их или оповещать при окончании интеграции.
* менеджер проекта — сугубо по желанию

= Профиты =

Так какую пользу можно получить о внедрения непрерывной интеграции в своем проекте?

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

Больше никаких «Это работает на моей машине!». Если что-то не работает на сборочном сервере — значит оно не работает вообще. Аргументы программиста, что у него все работает в данном случае не помогут. Сервер интеграции становиться судьей в таких вопросах и этот судья беспристрастен.

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

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

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

= Continuous Improvement =

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

= Ссылки =

== Публикации ==

* [http://www.martinfowler.com/articles/continuousIntegration.html Continuous Integration] — статья Мартина Фаулера (Martin Fowler) по Continuous Integration
* [http://www.jamesshore.com/Blog/Continuous-Integration-on-a-Dollar-a-Day.html Continuous Integration on a Dollar a Day] — статья Джеймса Шора (James Shore) о ручном методе интеграции
* [http://blogs.msdn.com/mswanson/articles/169058.aspx Automated Continuous Integration and the Ambient Orb] — статья Майка Свонсона (Mike Swanson)
* [http://c2.com/cgi/wiki?ContinuousIntegration c2.com] — статья по Continuous Integration в wiki на c2.com
* [http://en.wikipedia.org/wiki/Continuous_Integration en.wikipedia.org] — статья по Continuous Integration в Wikipedia
* [http://ru.wikipedia.org/wiki/Непрерывная_интеграция ru.wikipedia.org] — статья по непрерывной интеграции в Википедии

== Инструменты ==

=== Сервера интеграции ===
* [http://cruisecontrol.sourceforge.net CruiseControl] — сервер интеграции для Java (см. так же [[CruiseControl]]).
* [http://studio.thoughtworks.com/cruise-continuous-integration ThoughtWorks Cruise] — коммерческий сервер интеграции от компании ThoughtWorks (есть бесплатная версия).
* [http://ccnet.sourceforge.net CruiseControl.NET] — сервер интеграции для .NET (см. так же [[CruiseControl.NET]])
* [http://cruisecontrolrb.thoughtworks.com CruiseControl.rb] — сервер интеграции для Ruby.
* [http://hudson.dev.java.net Hudson] — open-source сервер интеграции, создан как альтернатива [[CruiseControl]]. Функциональность расширяется плагинами.
* [http://bitten.edgewall.org Bitten] — open-source сервер интеграции написанный на [[Python]], интегрируется с [[Trac]].
* [http://www.jetbrains.com/teamcity/index.html TeamCity] — коммерческий сервер интеграции от компаниии JetBrains для java и .NET (есть бесплатная версия).

=== Инструменты сборки ===
* [http://ant.apache.org Ant] — средство сборки для Java
* [http://maven.apache.org Maven] — средство сборки для Java
* [http://nant.sourceforge.net/ NAnt] — аналог Ant под .NET

=== Статический анализ ===
* [http://pmd.sourceforge.net PMD] — анализ кода Java
* [http://findbugs.sourceforge.net Findbugs] — анализ кода на типичные ошибки
* [http://www.redhillconsulting.com.au/products/simian/ Simian] — поиск повторов (copу+paste) в коде Java
* [http://www.gotdotnet.com/team/fxcop/ FXCop] — анализ кода .NET
* [http://qalab.sourceforge.net/index.html QALab] — объединение логов нескольких инструментов анализа кода, сбор статистики
* [http://www.panopticode.org/ Panopticode] — объединение логов нескольких инструментов анализа кода для Java, графическое представление результатов

=== Модульное тестирование и покрытие ===
* [http://junit.org JUnit] — де-факто стандарт модульного тестирования Java
* [http://testng.org TestNG] — инструмент нового поколения для модульного тестирования Java
* [http://www.nunit.org/ NUnit] — модульные тесты для приложений .NET
* [http://cobertura.sourceforge.net Cobertura] — измерение покрытия кода модульными тестами для Java
* [http://www.atlassian.com/software/clover/ Clover] — анализ покрытия кода тестами для Java
* [http://www.cenqua.com/clovernet/ Clover.NET] — анализ покрытия кода тестами под .NET

[[Категория:Программирование]]
[[Категория:Тестирование программного обеспечения]]
{{replicate-from-custiswiki-to-lib}}

Continuous Integration

2008-07-29T06:45:33Z

Andrew:

= Введение =
«Continuous Integration» — это лекарство от страха. Помогает при программировании.
Dr. Zoidberg ©

Согласно [http://en.wikipedia.org/wiki/Continuous_Integration Wikipedia] термин Continuous Integration введен Мартином Фаулером (Martin Fowler) и Кентом Беком (Kent Beck). Данный термин был придуман ими для обозначения практики частой сборки (интеграции) проекта. Максимально частая сборка является логичным продолжением цепочки
редкие сборки под релизы->ночные сборки->непрерывные сборки

В настоящее время Continuous Integration (непрерывная интеграция) одна из практик применяемых в семействе гибких (Agile) методологий. В подобных методологиях она удачно сочетается с другими практиками, такими как модульное(unit) тестирование, рефакторинг, стандарт кодирования. Но даже без них модно получить пользу от непрерывной интеграции.

= Основные принципы =

== Каждое изменение должно интегрироваться ==

Слово continuous в термине [[Continuous Integration]] означает «непрерывный/непрекращающийся». Это означает, что в идеале сборка вашего проекта должна идти буквально все время. Каждое изменение в системе контроля версий (например [[CVS]]) должно интегрироваться без пропусков или задержек. Организация ночных сборок — это хорошая практика, но это не continuous integration. Ведь результаты такой ночной сборки будут доступны лишь на следующий день, когда их актуальность для разработчиков уже значительно снижена. На практике довольно часто реализуют оба процесса и непрерывную интеграция и ночные сборки — более редкую интеграцию.
В очень крупных проектах это требование иногда невозможно соблюсти, но интеграция каждые сутки это предел за который не стоит уходить.
Принцип непрерывной интеграции не выполним без другого условия — «Сборка должна идти быстро».

== Быстрая сборка ==

«Сборка должна идти быстро» — точнее не более 10 минут. Если после одного небольшого коммита ваш интеграционный сервер будет уходить в 2-х часовое пыхтение на сборку, тестирование и разворачивание от этого будет мало пользы. Разработчики будут уже далеко, над решение других проблем, им будет сложно вернуться и понять причины сбоя, если таковой был. Ведь суть непрерывной интеграции в получении быстрого feedback. Вдобавок, поздний ответ с сервера может отвлечь их от другого дела.

В случае если все этапы процесса никак не удается втиснуть в приемлемые временные рамки можно разделить его на несколько частей. При каждом коммите производить лишь саму сборку и минимальный набор тестов (smoke tests), чтобы уменьшить время. А по ночам проводить полный цикл интеграции, результаты которого команда будет анализировать с утра. Но это скорее вынужденная мера, а не пример для подражания.

== Сделайте тесты ==

Тесты просто необходимо включать в continuous integration процесс, в противном случае вы не можете быть уверены в качестве и работоспособности своего проекта. Чем тестов больше, тем лучше, в разумных пределах конечно. Основными двумя ограничителями на количество тестов будет:
* время интеграции — сборка по-прежнему должна оставаться быстрой, основное тестирование можно перенести «на ночь»,
* наличие автоматизированных тестов — не все тесты требуют автоматизации, нет смысла делать автоматизированные тесты только для самих тестов, они должны быть целесообразны.

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

Именнно присутствие тестов одно из отличий интеграции от нажатия кнопки Build в вашей любимой IDE.

== Интеграция на специальной машине ==

Организовывать процесс необходимо на специально выделенной машине.
Такая машина по своей конфигурации и набору прикладных программ должна максимально соответствовать окружению в котором проект будет развернут (production enviroment). Очевидно, что полного совпадения достичь практически невозможно — маловероятно, что эксплуатироватся программа будет на машине с установленными средствами сборки, тестирования и проч. Но точное совпадение версий операционных систем (и сервис паков) необходимо.

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

= Методы =

== Continuous Integration сервер ==

Хотя в принципе практика continuous integration не требует никакого технического и программного обеспечения, гораздо удобнее, проще и дешевле наладить процесс с использованием таких средств. Такие средства называются сервера интеграции (continuous integration server)- специализированные приложения для автоматизации данного процесса.

Наиболее известный из серверов интеграции пожалуй [[CruiseControl]]. [[CruiseControl]] это сервер для интеграции приложений на java, написанный на java. Так же широко распространен его собрат (точнее портированная версия) под .NET — [[CruiseControl.NET]].

Ниже приведена схема организации такого сервера интеграции:
<graph>
digraph G{
rankdir=LR

Trigger [shape="box", style="filled", fillcolor="green", label="Trigger", URL="#Trigger"]
BuildLoop [shape="box", style="filled", fillcolor="yellow", label="Build Loop", URL="#Build_Loop"]
Report [shape="box", style="filled", fillcolor="yellow", label="Reporting App", URL="#Report"]
ExtApps [shape="box", style="filled", fillcolor="yellow", label="External Applications", URL="#Инструменты"]
Logs [shape="box", style="filled", fillcolor="yellow", label="Logs", URL="#Logs"]
Team [shape="box", style="filled", fillcolor="green", label="Team", URL="#Team"]

subgraph cluster_machine{
node [style=filled];
label = "Build Machine";
URL="#Build_Machine"

subgraph cluster_server{
node [style=filled];
BuildLoop -> Report;

label = "CI Server";
URL="#Continuous_Integration_сервер"
color=blue;
}

ExtApps->BuildLoop; /*->Logs;*/
ExtApps->Logs->Report;
color=blue;
}

Trigger->BuildLoop;
BuildLoop->ExtApps;
Report->Team;
}
</graph>

== Ручной процесс ==

Хотя решение с выделенным сервером для continuous integration кажется простым и дешевым, у него есть противники. Точнее, сторонники ручного процесса. Один из таких Джеймс Шор (James Shore) в своей статье [http://www.jamesshore.com/Blog/Continuous-Integration-on-a-Dollar-a-Day.html Continuous Integration on a Dollar a Day] пишет, как правильно организовать continuous integration процесс без специализированных приложений, вроде [[CruiseControl]]. В этой статье мы не касаемся данного вопроса.

= Процесс интеграции =

Continuous integration процесс состоит из нескольких этапов, некоторые из которых обязательны, другие нет:
* [[#Trigger|Trigger]] — обязателен
* [[#Update|Update]] — обязателен
* [[#Analyse|Analyse]] — не обязателен
* [[#Build|Build]] — а как без него?
* [[#UnitTest|UnitTest]] — крайне желателен
* [[#Deploy|Deploy]] — нужен по обстоятельствам
* [[#Test|Test]] — не обязателен, но крайне желателен
* [[#Archive|Archive]] — желателен
* [[#Report|Report]] — обязателен

== Trigger ==

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

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

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

== Update ==

На данном этапе CI сервер делает update своей локальной копии исходного кода проекта. В процессе update выясняются изменения в коде (и не только) произошедшие с последненй интеграции. Выяснение изменений необходимо для того, чтобы в случае сбоя можно было легко выяснить причину и найти ответственного.

== Analyse ==

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

Данный этап является необязательным для процесса continuous integration, но в случае его наличия можно получить дополнительный преимущества от введения практики в виде метрик по коду. Данный этап подразумевает не только получение статических характеристик кода, но и их включение в отчеты создаваемые сервером интеграции (о отчетах смотрите [[#Report|здесь]]).

== Build ==

Один из основных этапов процесса это сборка проекта. Здесь происходит компиляция (трансляция) исходных кодов в исполнимые файлы или какой-то другой результат. Поскольку сервер интеграции представляет собой специально выделенную машину (смотрите [[#Интеграция_на_специальной_машине|здесь]]) со строго определенной конфигурацией, результат только этой сборки можно считать конечным. Больше никаких «Проект собирается на моей машине!». Есть только одно место, где проект может собираться — это интеграционный сервер.

Естественно сборка является обязательным этапом интеграции.

== UnitTest ==

В методологии Extreme Programming модульное (unit) тестирование является неотъемлемой частью разработки приложения. Модульные тесты изначально автоматизированы, их включение в процесс интеграции крайне желательно. Поскольку часто у разработчиков нет времени или желания запускать такие тесты до того как изменения отправлены в систему контроля версий, дополнительное их исполнение никогда не будет лишним.
Дополнительную информацию можно извлечь, измеряя покрытие модульных тестов. Эта метрика поможет лучше контролировать качество выпускаемого продукта.

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

== Deploy ==

После того как мы убедились в некоторой работоспособности проекта — он собирается (этап [[#Build|Build]]) и все модульные тесты проходят ([[#UnitTest|UnitTest]]) проект необходимо «развернуть». В случае веб-приложения это выкладывание на веб-сервер (сервер приложений) и запуск. Для GUI приложений это (пере)установка в системе.

Этап развертывание должен проходить как можно более «чисто», подробнее смотрите [[#Интеграция_на_специальной_машине|здесь]]. При этом для последующего тестирования часто необходимо привести приложение в некое «стандартное» состояние:
* «залить» дамп базы
* настроить в стандартном режиме
* убрать следы предыдущей деятельности приложения

== Test ==

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

После прохождения регрессионных тестов можно считать, что интеграция прошла успешно и в проект не внесено правок, которые могут привести к его неработоспособности (здесь все зависит от вашего набора тестов модульных и функциональных). В противном случае интеграция не успешна — код содержит ошибки и требуется его исправление/доработка.

Тестирование это один из «фатальных» этапов процесса, ошибка на котором означает сбой сборки. Всего есть несколько таких «фатальных» этапов:
* [[#Build|Build]] — проект не собирается
* [[#UnitTest|UnitTest]] — модульные тест не прошли или покрытие упало ниже заданного уровня
* [[#Test|Test]] — регрессионные тесты не прошли или покрытие упало ниже заданного уровня

Иногда к ним присоединяют этап [[#Analyse|Analyse]] — если в коде обнаружено несоответствие стандартам кодирования, то это является ошибкой.

== Archive ==

После того как достигнута максимальная уверенность в качестве исходного кода необходимо сохранить его. Это можно сделать, например, посредством меток в системе контроля версий. Так же необходимо сохранить бинарные файлы проекта. Они могут понадобиться, если нужно будет воспроизвести ошибку в конкретной версии и для ручного тестирования.

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

== Report ==

В конце идет важный этап генерации и публикации отчетов. Отчеты включают в себя следующее:
* причина сборки — например изменения в репозитории
* изменения в исходных кодах — здесь возможны два варианта изменения от последней сборки или от последней успешной сборки
* отчеты по статическому анализу кода — все результаты какие есть
* лог сборки
* лог модульных тестов — какие тесты прошли и, что важнее, какие не прошли
* лог регрессионных тестов — аналогично модульным тестам
* статистика сборок проекта:
** общее число удачных/провальных сборок
** распределение удачных/провальных сборок во времени
** статистика результатов статического анализа кода
* все другие метрики используемые и собираемые в проекте — это поможет менеджеру проекта видеть все и сразу

Механизм публикации отчета может быть разный и даже не один. Это может быть IRC или jabber бот, рассылка по электронной почте, публикация на web или ftp сервере, специализированные клиенты позволяющие узнать статус сборки.

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

Для правильной организации данного этапа важно понимать кого и как необходимо оповещать о результатах интеграции. Здесь надо выбрать между двумя крайностями — оповещать всегда или никогда. Примерное решение этой задачи будет таким:
* разработчики — минимум при сбое интеграции, в противном случае, как разработчик узнает, что внесенные им изменения сломали код? Конечно, можно оповещать и всегда, это зависит от частоты сборок.
* тестировщики — если они входят в команду, то оповещать тогда же, когда и разработчиков, ведь иногда ошибки могут быть и в тестах. Если практикуется независимое тестирование вообще не оповещать их или оповещать при окончании интеграции.
* менеджер проекта — сугубо по желанию

= Профиты =

Так какую пользу можно получить о внедрения непрерывной интеграции в своем проекте?

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

Больше никаких «Это работает на моей машине!». Если что-то не работает на сборочном сервере — значит оно не работает вообще. Аргументы программиста, что у него все работает в данном случае не помогут. Сервер интеграции становиться судьей в таких вопросах и этот судья беспристрастен.

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

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

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

= Continuous Improvement =

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

= Ссылки =

== Публикации ==

* [http://www.martinfowler.com/articles/continuousIntegration.html Continuous Integration] — статья Мартина Фаулера (Martin Fowler) по Continuous Integration
* [http://www.jamesshore.com/Blog/Continuous-Integration-on-a-Dollar-a-Day.html Continuous Integration on a Dollar a Day] — статья Джеймса Шора (James Shore) о ручном методе интеграции
* [http://blogs.msdn.com/mswanson/articles/169058.aspx Automated Continuous Integration and the Ambient Orb] — статья Майка Свонсона (Mike Swanson)
* [http://c2.com/cgi/wiki?ContinuousIntegration c2.com] — статья по Continuous Integration в wiki на c2.com
* [http://en.wikipedia.org/wiki/Continuous_Integration en.wikipedia.org] — статья по Continuous Integration в Wikipedia
* [http://ru.wikipedia.org/wiki/Непрерывная_интеграция ru.wikipedia.org] — статья по непрерывной интеграции в Википедии

== Инструменты ==

=== Сервера интеграции ===
* [http://cruisecontrol.sourceforge.net CruiseControl] — сервер интеграции для Java (см. так же [[CruiseControl]]).
* [http://studio.thoughtworks.com/cruise-continuous-integration ThoughtWorks Cruise] — коммерческий сервер интеграции от компании ThoughtWorks (есть бесплатная версия).
* [http://ccnet.sourceforge.net CruiseControl.NET] — сервер интеграции для .NET (см. так же [[CruiseControl.NET]])
* [http://cruisecontrolrb.thoughtworks.com CruiseControl.rb] — сервер интеграции для Ruby.
* [http://hudson.dev.java.net Hudson] — open-source сервер интеграции, создан как альтернатива [[CruiseControl]]. Функциональность расширяется плагинами.
* [http://bitten.edgewall.org Bitten] — open-source сервер интеграции написанный на [[Python]], интегрируется с [[Trac]].
* [http://www.jetbrains.com/teamcity/index.html TeamCity] — коммерческий сервер интеграции от компаниии JetBrains для java и .NET (есть бесплатная версия).

=== Инструменты сборки ===
* [http://ant.apache.org Ant] — средство сборки для Java
* [http://maven.apache.org Maven] — средство сборки для Java
* [http://nant.sourceforge.net/ NAnt] — аналог Ant под .NET

=== Статический анализ ===
* [http://pmd.sourceforge.net PMD] — анализ кода Java
* [http://findbugs.sourceforge.net Findbugs] — анализ кода на типичные ошибки
* [http://www.redhillconsulting.com.au/products/simian/ Simian] — поиск повторов (copу+paste) в коде Java
* [http://www.gotdotnet.com/team/fxcop/ FXCop] — анализ кода .NET
* [http://qalab.sourceforge.net/index.html QALab] — объединение логов нескольких инструментов анализа кода, сбор статистики
* [http://www.panopticode.org/ Panopticode] — объединение логов нескольких инструментов анализа кода для Java, графическое представление результатов

=== Модульное тестирование и покрытие ===
* [http://junit.org JUnit] — де-факто стандарт модульного тестирования Java
* [http://testng.org TestNG] — инструмент нового поколения для модульного тестирования Java
* [http://www.nunit.org/ NUnit] — модульные тесты для приложений .NET
* [http://cobertura.sourceforge.net Cobertura] — измерение покрытия кода модульными тестами для Java
* [http://www.atlassian.com/software/clover/ Clover] — анализ покрытия кода тестами для Java
* [http://www.cenqua.com/clovernet/ Clover.NET] — анализ покрытия кода тестами под .NET

[[Категория:Программирование]]
[[Категория:Тестирование программного обеспечения]]
{{replicate-from-custiswiki-to-lib}}

Continuous Integration

2008-07-29T06:44:48Z

Andrew: /* Сервера интеграции */

= Введение =
«Continuous Integration» — это лекарство от страха. Помогает при программировании.
Dr. Zoidberg ©

Согласно [http://en.wikipedia.org/wiki/Continuous_Integration Wikipedia] термин Continuous Integration введен Мартином Фаулером (Martin Fowler) и Кентом Беком (Kent Beck). Данный термин был придуман ими для обозначения практики частой сборки (интеграции) проекта. Максимально частая сборка является логичным продолжением цепочки
редкие сборки под релизы->ночные сборки->непрерывные сборки

В настоящее время Continuous Integration (непрерывная интеграция) одна из практик применяемых в семействе гибких (Agile) методологий. В подобных методологиях она удачно сочетается с другими практиками, такими как модульное(unit) тестирование, рефакторинг, стандарт кодирования. Но даже без них модно получить пользу от непрерывной интеграции.

= Основные принципы =

== Каждое изменение должно интегрироваться ==

Слово continuous в термине [[Continuous Integration]] означает «непрерывный/непрекращающийся». Это означает, что в идеале сборка вашего проекта должна идти буквально все время. Каждое изменение в системе контроля версий (например [[CVS]]) должно интегрироваться без пропусков или задержек. Организация ночных сборок — это хорошая практика, но это не continuous integration. Ведь результаты такой ночной сборки будут доступны лишь на следующий день, когда их актуальность для разработчиков уже значительно снижена. На практике довольно часто реализуют оба процесса и непрерывную интеграция и ночные сборки — более редкую интеграцию.
В очень крупных проектах это требование иногда невозможно соблюсти, но интеграция каждые сутки это предел за который не стоит уходить.
Принцип непрерывной интеграции не выполним без другого условия — «Сборка должна идти быстро».

== Быстрая сборка ==

«Сборка должна идти быстро» — точнее не более 10 минут. Если после одного небольшого коммита ваш интеграционный сервер будет уходить в 2-х часовое пыхтение на сборку, тестирование и разворачивание от этого будет мало пользы. Разработчики будут уже далеко, над решение других проблем, им будет сложно вернуться и понять причины сбоя, если таковой был. Ведь суть непрерывной интеграции в получении быстрого feedback. Вдобавок, поздний ответ с сервера может отвлечь их от другого дела.

В случае если все этапы процесса никак не удается втиснуть в приемлемые временные рамки можно разделить его на несколько частей. При каждом коммите производить лишь саму сборку и минимальный набор тестов (smoke tests), чтобы уменьшить время. А по ночам проводить полный цикл интеграции, результаты которого команда будет анализировать с утра. Но это скорее вынужденная мера, а не пример для подражания.

== Сделайте тесты ==

Тесты просто необходимо включать в continuous integration процесс, в противном случае вы не можете быть уверены в качестве и работоспособности своего проекта. Чем тестов больше, тем лучше, в разумных пределах конечно. Основными двумя ограничителями на количество тестов будет:
* время интеграции — сборка по-прежнему должна оставаться быстрой, основное тестирование можно перенести «на ночь»,
* наличие автоматизированных тестов — не все тесты требуют автоматизации, нет смысла делать автоматизированные тесты только для самих тестов, они должны быть целесообразны.

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

Именнно присутствие тестов одно из отличий интеграции от нажатия кнопки Build в вашей любимой IDE.

== Интеграция на специальной машине ==

Организовывать процесс необходимо на специально выделенной машине.
Такая машина по своей конфигурации и набору прикладных программ должна максимально соответствовать окружению в котором проект будет развернут (production enviroment). Очевидно, что полного совпадения достичь практически невозможно — маловероятно, что эксплуатироватся программа будет на машине с установленными средствами сборки, тестирования и проч. Но точное совпадение версий операционных систем (и сервис паков) необходимо.

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

= Методы =
== Continuous Integration сервер ==

Хотя в принципе практика continuous integration не требует никакого технического и программного обеспечения, гораздо удобнее, проще и дешевле наладить процесс с использованием таких средств. Такие средства называются сервера интеграции (continuous integration server)- специализированные приложения для автоматизации данного процесса.

Наиболее известный из серверов интеграции пожалуй [[CruiseControl]]. [[CruiseControl]] это сервер для интеграции приложений на java, написанный на java. Так же широко распространен его собрат (точнее портированная версия) под .NET — [[CruiseControl.NET]].

Ниже приведена схема организации такого сервера интеграции:
<graph>
digraph G{
rankdir=LR

Trigger [shape="box", style="filled", fillcolor="green", label="Trigger", URL="#Trigger"]
BuildLoop [shape="box", style="filled", fillcolor="yellow", label="Build Loop", URL="#Build_Loop"]
Report [shape="box", style="filled", fillcolor="yellow", label="Reporting App", URL="#Report"]
ExtApps [shape="box", style="filled", fillcolor="yellow", label="External Applications", URL="#Инструменты"]
Logs [shape="box", style="filled", fillcolor="yellow", label="Logs", URL="#Logs"]
Team [shape="box", style="filled", fillcolor="green", label="Team", URL="#Team"]

subgraph cluster_machine{
node [style=filled];
label = "Build Machine";
URL="#Build_Machine"

subgraph cluster_server{
node [style=filled];
BuildLoop -> Report;

label = "CI Server";
URL="#Continuous_Integration_сервер"
color=blue;
}

ExtApps->BuildLoop; /*->Logs;*/
ExtApps->Logs->Report;
color=blue;
}

Trigger->BuildLoop;
BuildLoop->ExtApps;
Report->Team;
}
</graph>

== Ручной процесс ==

Хотя решение с выделенным сервером для continuous integration кажется простым и дешевым, у него есть противники. Точнее, сторонники ручного процесса. Один из таких Джеймс Шор (James Shore) в своей статье [http://www.jamesshore.com/Blog/Continuous-Integration-on-a-Dollar-a-Day.html Continuous Integration on a Dollar a Day] пишет, как правильно организовать continuous integration процесс без специализированных приложений, вроде [[CruiseControl]]. В этой статье мы не касаемся данного вопроса.

= Процесс интеграции =

Continuous integration процесс состоит из нескольких этапов:
* [[#Trigger|Trigger]]- от этого не избавиться
* [[#Update|Update]] — обязателен
* [[#Analyse|Analyse]] — не обязателен
* [[#Build|Build]] — а как без него?
* [[#UnitTest|UnitTest]] — крайне желателен
* [[#Deploy|Deploy]] — нужен по обстоятельствам
* [[#Test|Test]] — не обязателен
* [[#Archive|Archive]] — желателен
* [[#Report|Report]] — обязателен

== Trigger ==

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

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

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

== Update ==

На данном этапе CI сервер делает update своей локальной копии исходного кода проекта. В процессе update выясняются изменения в коде (и не только) произошедшие с последненй интеграции. Выяснение изменений необходимо для того, чтобы в случае сбоя можно было легко выяснить причину и найти ответственного.

== Analyse ==

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

Данный этап является необязательным для процесса continuous integration, но в случае его наличия можно получить дополнительный преимущества от введения практики в виде метрик по коду. Данный этап подразумевает не только получение статических характеристик кода, но и их включение в отчеты создаваемые сервером интеграции (о отчетах смотрите [[#Report|здесь]]).

== Build ==

Один из основных этапов процесса это сборка проекта. Здесь происходит компиляция (трансляция) исходных кодов в исполнимые файлы или какой-то другой результат. Поскольку сервер интеграции представляет собой специально выделенную машину (смотрите [[#Интеграция_на_специальной_машине|здесь]]) со строго определенной конфигурацией, результат только этой сборки можно считать конечным. Больше никаких «Проект собирается на моей машине!». Есть только одно место, где проект может собираться — это интеграционный сервер.

Естественно сборка является обязательным этапом интеграции.

== UnitTest ==

В методологии Extreme Programming модульное (unit) тестирование является неотъемлемой частью разработки приложения. Модульные тесты изначально автоматизированы, их включение в процесс интеграции крайне желательно. Поскольку часто у разработчиков нет времени или желания запускать такие тесты до того как изменения отправлены в систему контроля версий, дополнительное их исполнение никогда не будет лишним.
Дополнительную информацию можно извлечь, измеряя покрытие модульных тестов. Эта метрика поможет лучше контролировать качество выпускаемого продукта.

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

== Deploy ==

После того как мы убедились в некоторой работоспособности проекта — он собирается (этап [[#Build|Build]]) и все модульные тесты проходят ([[#UnitTest|UnitTest]]) проект необходимо «развернуть». В случае веб-приложения это выкладывание на веб-сервер (сервер приложений) и запуск. Для GUI приложений это (пере)установка в системе.

Этап развертывание должен проходить как можно более «чисто», подробнее смотрите [[#Интеграция_на_специальной_машине|здесь]]. При этом для последующего тестирования часто необходимо привести приложение в некое «стандартное» состояние:
* «залить» дамп базы
* настроить в стандартном режиме
* убрать следы предыдущей деятельности приложения

== Test ==

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

После прохождения регрессионных тестов можно считать, что интеграция прошла успешно и в проект не внесено правок, которые могут привести к его неработоспособности (здесь все зависит от вашего набора тестов модульных и функциональных). В противном случае интеграция не успешна — код содержит ошибки и требуется его исправление/доработка.

Тестирование это один из «фатальных» этапов процесса, ошибка на котором означает сбой сборки. Всего есть несколько таких «фатальных» этапов:
* [[#Build|Build]] — проект не собирается
* [[#UnitTest|UnitTest]] — модульные тест не прошли или покрытие упало ниже заданного уровня
* [[#Test|Test]] — регрессионные тесты не прошли или покрытие упало ниже заданного уровня

Иногда к ним присоединяют этап [[#Analyse|Analyse]] — если в коде обнаружено несоответствие стандартам кодирования, то это является ошибкой.

== Archive ==

После того как достигнута максимальная уверенность в качестве исходного кода необходимо сохранить его. Это можно сделать, например, посредством меток в системе контроля версий. Так же необходимо сохранить бинарные файлы проекта. Они могут понадобиться, если нужно будет воспроизвести ошибку в конкретной версии и для ручного тестирования.

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

== Report ==

В конце идет важный этап генерации и публикации отчетов. Отчеты включают в себя следующее:
* причина сборки — например изменения в репозитории
* изменения в исходных кодах — здесь возможны два варианта изменения от последней сборки или от последней успешной сборки
* отчеты по статическому анализу кода — все результаты какие есть
* лог сборки
* лог модульных тестов — какие тесты прошли и, что важнее, какие не прошли
* лог регрессионных тестов — аналогично модульным тестам
* статистика сборок проекта:
** общее число удачных/провальных сборок
** распределение удачных/провальных сборок во времени
** статистика результатов статического анализа кода
* все другие метрики используемые и собираемые в проекте — это поможет менеджеру проекта видеть все и сразу

Механизм публикации отчета может быть разный и даже не один. Это может быть IRC или jabber бот, рассылка по электронной почте, публикация на web или ftp сервере, специализированные клиенты позволяющие узнать статус сборки.

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

Для правильной организации данного этапа важно понимать кого и как необходимо оповещать о результатах интеграции. Здесь надо выбрать между двумя крайностями — оповещать всегда или никогда. Примерное решение этой задачи будет таким:
* разработчики — минимум при сбое интеграции, в противном случае, как разработчик узнает, что внесенные им изменения сломали код? Конечно, можно оповещать и всегда, это зависит от частоты сборок.
* тестировщики — если они входят в команду, то оповещать тогда же, когда и разработчиков, ведь иногда ошибки могут быть и в тестах. Если практикуется независимое тестирование вообще не оповещать их или оповещать при окончании интеграции.
* менеджер проекта — сугубо по желанию

= Профиты =

Так какую пользу можно получить о внедрения непрерывной интеграции в своем проекте?

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

Больше никаких «Это работает на моей машине!». Если что-то не работает на сборочном сервере — значит оно не работает вообще. Аргументы программиста, что у него все работает в данном случае не помогут. Сервер интеграции становиться судьей в таких вопросах и этот судья беспристрастен.

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

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

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

= Continuous Improvement =

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

= Ссылки =

== Публикации ==

* [http://www.martinfowler.com/articles/continuousIntegration.html Continuous Integration] — статья Мартина Фаулера (Martin Fowler) по Continuous Integration
* [http://www.jamesshore.com/Blog/Continuous-Integration-on-a-Dollar-a-Day.html Continuous Integration on a Dollar a Day] — статья Джеймса Шора (James Shore) о ручном методе интеграции
* [http://blogs.msdn.com/mswanson/articles/169058.aspx Automated Continuous Integration and the Ambient Orb] — статья Майка Свонсона (Mike Swanson)
* [http://c2.com/cgi/wiki?ContinuousIntegration c2.com] — статья по Continuous Integration в wiki на c2.com
* [http://en.wikipedia.org/wiki/Continuous_Integration en.wikipedia.org] — статья по Continuous Integration в Wikipedia
* [http://ru.wikipedia.org/wiki/Непрерывная_интеграция ru.wikipedia.org] — статья по непрерывной интеграции в Википедии

== Инструменты ==
=== Сервера интеграции ===
* [http://cruisecontrol.sourceforge.net CruiseControl] — сервер интеграции для Java (см. так же [[CruiseControl]]).
* [http://studio.thoughtworks.com/cruise-continuous-integration ThoughtWorks Cruise] — коммерческий сервер интеграции от компании ThoughtWorks (есть бесплатная версия).
* [http://ccnet.sourceforge.net CruiseControl.NET] — сервер интеграции для .NET (см. так же [[CruiseControl.NET]])
* [http://cruisecontrolrb.thoughtworks.com CruiseControl.rb] — сервер интеграции для Ruby.
* [http://hudson.dev.java.net Hudson] — open-source сервер интеграции, создан как альтернатива [[CruiseControl]]. Функциональность расширяется плагинами.
* [http://bitten.edgewall.org Bitten] — open-source сервер интеграции написанный на [[Python]], интегрируется с [[Trac]].
* [http://www.jetbrains.com/teamcity/index.html TeamCity] — коммерческий сервер интеграции от компаниии JetBrains для java и .NET (есть бесплатная версия).

=== Инструменты сборки ===
* [http://ant.apache.org Ant] — средство сборки для Java
* [http://maven.apache.org Maven] — средство сборки для Java
* [http://nant.sourceforge.net/ NAnt] — аналог Ant под .NET

=== Статический анализ ===
* [http://pmd.sourceforge.net PMD] — анализ кода Java
* [http://findbugs.sourceforge.net Findbugs] — анализ кода на типичные ошибки
* [http://www.redhillconsulting.com.au/products/simian/ Simian] — поиск повторов (copу+paste) в коде Java
* [http://www.gotdotnet.com/team/fxcop/ FXCop] — анализ кода .NET
* [http://qalab.sourceforge.net/index.html QALab] — объединение логов нескольких инструментов анализа кода, сбор статистики
* [http://www.panopticode.org/ Panopticode] — объединение логов нескольких инструментов анализа кода для Java, графическое представление результатов

=== Модульное тестирование и покрытие ===
* [http://junit.org JUnit] — де-факто стандарт модульного тестирования Java
* [http://testng.org TestNG] — инструмент нового поколения для модульного тестирования Java
* [http://www.nunit.org/ NUnit] — модульные тесты для приложений .NET
* [http://cobertura.sourceforge.net Cobertura] — измерение покрытия кода модульными тестами для Java
* [http://www.atlassian.com/software/clover/ Clover] — анализ покрытия кода тестами для Java
* [http://www.cenqua.com/clovernet/ Clover.NET] — анализ покрытия кода тестами под .NET

[[Category:Программирование]]
[[Category:Тестирование программного обеспечения]]
{{replicate-from-custiswiki-to-lib}}

Интеграция Open Source-систем для управления разработкой ПО

2007-12-29T13:57:20Z

Andrew:

[[Участник:StasFomin|Стас Фомин]] на [http://secr.ru SECR-2007] был представил доклад «Интеграция Open Source-систем для управления разработкой ПО».
* [http://stanislav.fomin.googlepages.com/secr-2007-open-source-4-development.pdf Доклад]
* [http://stanislav.fomin.googlepages.com/secr-2007-show-open-source-4-develop.pdf Презентация]

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

[[{{SITENAME}}]] конечно не форум, но ее вполне можно использовать для обсуждения, см.
[[Help:Советы#Замечания и обсуждения]]. Вообще, рекомендуется хотя бы просмотреть [[Help:Contents|справочный раздел]]. Если вдруг не получится зарегистрироваться,
(да, там есть некоторая защита от спамеров), то свяжитесь с stas@custis.ru — все решим.

ExecMain.html (TestLink-RU)

2007-10-07T13:34:01Z

Andrew:

ExecFilter.html (TestLink-RU)

2007-10-07T13:33:09Z

Andrew:

[[Category:TestLink]]
<code-xml>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
<head>
<meta name="generator" content=
"HTML Tidy for Windows (vers 14 February 2006), see www.w3.org" />
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta http-equiv="pragma" content="no-cache" />
<meta name="author" content="Martin Havlat" />
<meta name="copyright" content="GNU" />
<meta name="robots" content="NOFOLLOW" />
<title>
TestLink Help: Test Filtering
</title>
<link rel="stylesheet" type="text/css" href=
"../../{$smarty.const.TL_THEME_CSS_DIR}tl_docs.css" />
</head>
<body>
<h1>
Отбор тестов
</h1>
<div id="menu">
<a href="javascript:%20window.close();" class="tlButton">Закрыть</a>
<a href="javascript:%20history.back();" class="tlButton">Назад</a>
<a href="content.html" class="tlButton">Оглавление</a>
</div>
<h2>
Назначение
</h2>
<p>
Данная таблица дает возможность пользователю отобрать тесты для прогона
по следующим параметрам.
</p>
<h2>
Принадлежность
</h2>
<p>
Пользователь может отбирать тесты по их владельцу. Принадлежность может
определятся как для целых групп так и для каждого теста в отдельности, ее задает руководитель (leader), и она
может быть изменена на странице "Поручить выполнение тестов".<br />
</p>
<h2>
Ключевое слово
</h2>
<p>
Пользователи могут делать выборку тестов по ключевому слову. Ключевые
слова задаются на странице Создания/ редактирования/ удаления тестов или
на странице "Привязать ключевые слова". Создание, редактирование и
удаление Ключевых слов является правом руководителя. Задавать ключевые
слова для тестов может и пользователь с правами тестера.
</p>
<h2>
Сборка (версия)
</h2>
<p>
Пользователи могут отбирать тесты для прогона по сборке
программного обеспечения. Сборка являются основным компонентом для
прослеживаемости тестов. Тест может быть запущен несколько раз на одной
сборке, но в отчетах фигурирует только последний результат выполнения теста над сборкой<br />
Сборки создаются руководителем на странице "Управление сборками".
</p>
<h2>
Результат прогона
</h2>
<p>
Пользователи могут отбирать тесты по результатам прогона на определенной
сборке. Тесты может быть пройденным, проваленным, блокированным
или невыполненным.
</p>
<h2>
Последний результат прогона
</h2>
<p>
По умолчанию или если не выбрано значение "Последний прогон", дерево
тестов будет отсортировано по выбранной версии. При этом в структуре
тестов цветом будет отображаться их статус.<br />
Например: На навигационной панели пользователь назначил отбор тестов по
версии 2, и не выбрал значение "последний прогон". В результате будут
показаны все тесты со своими статусами из версии 2. Так, если тест 1
пройден в версии 2, то он будет отображаться зеленым цветом.<br />
Если пользователь решил задать значение "последний прогон" тесты в дереве
будут окрашено согласно результатам последнего прогона.<br />
Например: Пользователь назначил отбор тестов по версии 2, и на этот раз
выбрал значение "последний прогон". Все тесты будут окрашены согласно
результату последнего прогона. Поэтому, если тест 1 оказался пройденным
только в версии 3, он будет выделен зеленым цветом, несмотря на то, что
пользователь выбрал версию 2.
</p>
</body>
</html>
</code-xml>

EditTc.html (TestLink-RU)

2007-10-07T13:29:01Z

Andrew:

[[Category:TestLink]]
<code-xml>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
<head>
<meta name="generator" content=
"HTML Tidy for Windows (vers 14 February 2006), see www.w3.org" />
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta http-equiv="Content-language" content="en" />
<meta name="author" content="Martin Havlat" />
<meta name="copyright" content="GNU" />
<meta name="robots" content="NOFOLLOW" />
<title>
Справка TestLink: Редактирование тестов
</title>
<style media="all" type="text/css">
/*<![CDATA[*/
@import "../../{$smarty.const.TL_THEME_CSS_DIR}testlink.css";
/*]]>*/
</style>
<script type="text/javascript" src="../../javascript/testlink_library.js">
</script>
</head>
<body>
<div class="workBack">
<h1>
Редактирование тестов
</h1>
<h2>
Назначение:
</h2>
<p>
В этом разделе пользователь может просмотреть и отредактировать
<span class="help" onclick=
"javascript:open_popup('./glosary.html#testcase');">тесты</span> и
группы тестов относящиеся к заданному <span class="help" onclick=
"javascript:open_popup('./glosary.html#product');">проекту</span>.
Пользователь не может просмотреть различные версии теста – база данных
содержит только последнюю (действующую) версию. Рекомендуется
распечатывать описания тестов в ходе тестирования.
</p>
<h2>
Что делать:
</h2>
<ol>
<li>Выберите название проекта из выпадающего меню, расположенного в
правом верхнем углу экрана.
</li>
<li>Создайте новые группы и тест для этого проекта.
</li>
<li>Используя древовидную структуру панели навигации слева,
отредактируйте описания тестовых примеров.
</li>
<li>Когда тест будет готов, включите его в соответствующий <span class="help"
onclick="javascript:open_popup('./glosary.html#testplan');">План
тестирования</span>.
</li>
</ol>
<h1 align="right">
см. также: <span class="help" onclick=
"javascript:open_popup('./content.html');">Справка TestLink</span>
</h1>
</div>
</body>
</html>
</code-xml>

Bug add.html (TestLink-RU)

2007-10-07T13:26:56Z

Andrew:

<code-xml>
<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<meta http-equiv="Content-language" content="en" />
<meta http-equiv="expires" content="-1" />
<meta http-equiv="pragma" content="no-cache" />
<meta name="author" content="Martin Havlat" />
<meta name="copyright" content="GNU" />
<meta name="robots" content="NOFOLLOW" />
<title>TestLink Instructions</title>
<style media="all" type="text/css">@import "../../{$smarty.const.TL_THEME_CSS_DIR}testlink.css";</style>
</head>
<body>

<div class="workback">
<h1>Привязка багов к тесту</h1>

<p>
TestLink очень примитивно интегрирован с системой управления ошибками (багами): <br/>
нет возможности ни создать баг в BTS (Bug Tracking System), ни получить
полную информацию по багу из неё (краткая информация по зарегистрированным багам показывается).<br/>
Интеграция заключается в использовании ссылок на страницы BTS, на которых и
осуществляется показ полной информации по багу и вставка новых багов.
</p>

<h2>Добавление бага</h2>
<ol>
<li>Используйте соответствующую ссылку, чтобы перейти на страницу добавления бага в BTS и вставить новый баг. </li>
<li>Запомните идентификатор бага (BUGID), присвоенный багу системой BTS.</li>
<li>Введите этот BUGID в соответствующее поле в TestLink'е, и нажмите кнопку «добавить».</li>
</ol>
Можно привязать к одному результату выполнения несколько багов сразу, достаточно ввести их номера через запятую в соответствующее поле в TestLink'е.
</div>
</body>
</html>
</code-xml>

BrowseResults.html (TestLink-RU)

2007-10-07T13:24:06Z

Andrew:

[[Category:TestLink]]
<code-xml>
<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<meta http-equiv="Content-language" content="en" />
<meta name="author" content="Martin Havlat" />
<meta name="copyright" content="GNU" />
<meta name="robots" content="NOFOLLOW" />
<title>TestLink Instructions</title>
<style media="all" type="text/css">@import "../../{$smarty.const.TL_THEME_CSS_DIR}testlink.css";</style>
</head>

<body>

<div class="workBack">

<h1>Отчеты о результатах тестирования</h1>

<h2>Общие метрики плана тестирования</h2>
<p>В данном отчете показаны результаты тестирования текущей сборки продукта.</p>

<h2>Общий статус всех сборок</h2>
<p>В данном отчете показан суммарный результат прогона тестов по каждой сборке продукта.</p>

<h2>Запрос метрик</h2>
<p>Данный отчет формируется на основе выбора пользователем следующих параметров испытаний: сборка продукта,
владелец теста, ключевые слова, статус результата последнего прогона теста.</p>

<h2>Отчет о прогоне тестов</h2>
<p>В данном отчете показаны тесты и результаты их прогона для всех версий продукта.<br />
В данном случае доступен экспорт отчета в файл формата Excel.</p>

<h2>Блокированные тесты</h2>
<p>В данном отчете показаны все тесты, блокированные в настоящий момент. <br />
Например, если тест был пройден в версии 1 и блокирован в версии 2, то он будет показан в этом отчете.<br />
А если он был блокирован в версии 1 и пройден в версии 2, то не будет. </p>

<h2>Проваленные тесты</h2>
<p>В данном отчете показаны все тесты, которые в настоящий момент провалены.</p>

<h2>Отчет об обнаруженных багах</h2>
<p>В данном отчете показаны все тесты заданного плана и все обнаруженные баги.</p>

<h2>Отчет о выполнении требований</h2>
<p>В данном отчете показаны результаты прогона тестов, спроецированные на покрываемые ими требования.</p>

<h2>Формат отчета</h2>
<p>Здесь пользователю предлагается возможность выбора способа предоставления отчета:
<ol>
<li>посмотреть отчет в веб интерфейсе системы TestLink,</li>
<li>отправить отчет на любой адрес электронной почты,</li>
<li>представить отчет в формате MS Excel.</li>
</ol>
</p>

<h1 align=right > см. также:
<span class="help"
onclick="javascript:open_popup('./content.html');"> Справка TestLink</span>
</h1>

</div>

</body>
</html>
</code-xml>

BrowseResults.html (TestLink-RU)

2007-10-07T13:23:19Z

Andrew:

[[Category:TestLink]]
<code-xml>
<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<meta http-equiv="Content-language" content="en" />
<meta name="author" content="Martin Havlat" />
<meta name="copyright" content="GNU" />
<meta name="robots" content="NOFOLLOW" />
<title>TestLink Instructions</title>
<style media="all" type="text/css">@import "../../{$smarty.const.TL_THEME_CSS_DIR}testlink.css";</style>
</head>

<body>

<div class="workBack">

<h1>Отчеты о результатах тестирования</h1>

<h2>Общие метрики плана тестирования</h2>
<p>В данном отчете показаны результаты тестирования текущей сборки продукта.</p>

<h2>Общий статус всех сборок</h2>
<p>В данном отчете показан суммарный результат прогона тестов по каждой сборке продукта.</p>

<h2>Запрос метрик</h2>
<p>Данный отчет формируется на основе выбора пользователем следующих параметров испытаний: сборка продукта,
владелец теста, ключевые слова, статус результата последнего прогона теста.</p>

<h2>Отчет о прогоне тестов</h2>
<p>В данном отчете показаны тесты и результаты их прогона для всех версий продукта.<br />
В данном случае доступен экспорт отчета в файл формата Excel.</p>

<h2>Блокированные тесты</h2>
<p>В данном отчете показаны все тесты, блокированные в настоящий момент. <br />
Например, если тест был пройден в версии 1 и блокирован в версии 2, то он будет показан в этом отчете.<br />
А если он был блокирован в версии 1 и пройден в версии 2, то не будет. </p>

<h2>Проваленные тесты</h2>
<p>В данном отчете показаны все тесты, которые в настоящий момент провалены.</p>

<h2>Отчет об обнаруженных багах</h2>
<p>В данном отчете показаны все тесты заданного плана и все обнаруженные баги.</p>

<h2>Отчет о выполнении требований</h2>
<p>В данном отчете показаны результаты прогона тестов, спроецированные на покрываемые ими требования.</p>

<h2>Формат отчета</h2>
<p>Здесь пользователю предлагается возможность выбора способа предоставления отчета:
* посмотреть отчет в веб интерфейсе системы TestLink
* отправить отчет на любой адрес электронной почты
* представить отчет в формате MS Excel
</p>

<h1 align=right > см. также:
<span class="help"
onclick="javascript:open_popup('./content.html');"> Справка TestLink</span>
</h1>

</div>

</body>
</html>
</code-xml>

Strings.txt (TestLink-RU)

2007-10-07T13:19:50Z

Andrew: /* lib/results/resultsNavigator.php */

[[Category:TestLink]]

Статьяz с основной локализацией интерфейса. Статья разбита по разделам, в соответствии с разделами в оригинальном файле <tt>strings.txt</tt>. По ссылке «[[#Скачать|скачать]]» можно получить готовый PHP-файл, который нужно разместить в каталоге
testlink\locale\ru_RU\strings.txt

=Скачать=
[{{SERVER}}{{localurl:Special:CisGetPHPPage|pagetitle={{PAGENAMEE}}}} Получить PHP-код]

= Оригинал (наиболее полный английский перевод) =
* http://testlink.cvs.sourceforge.net/testlink/testlink/locale/en_GB/

=Разделы файла strings.txt (ru_RU)=
<code-php>
/**
* TestLink Open Source Project - http://testlink.sourceforge.net/
*
* Filename $RCSfile: strings.txt,v $
*
* @version $Revision$
* @modified $Date$ $Author$
*
* @author Vadim Ivanchenko, Stas Fomin, and russian Testlink community.
* http://lib.custis.ru/index.php/TestLink:_strings.txt_%28RU%29
*
*
**/

$TLS_STRINGFILE_CHARSET = "UTF-8";
</code-php>

==General==
<code-php>
$TLS_asc = "по возрастанию";
$TLS_btn_no = "Нет";
$TLS_create = "Создать";
$TLS_desc = "по убыванию";
$TLS_test_case = "Тест";
$TLS_testcase = $TLS_test_case;
$TLS_test_plan = "План тестирования";
$TLS_testplan = $TLS_test_plan;
$TLS_test_suite = "Группа тестов";
$TLS_SRS = "SRS";
$TLS_Role = "Роль";
$TLS_Keyword = "Ключевое слово";
$TLS_Milestone = "Веха";
$TLS_testsuite_created = "Группа тестов создана";
$TLS_requirement = "Требование";
$TLS_assigned = "назначен";
$TLS_unassigned = "свободен";
$TLS_import_file_type = "Тип импортируемого файла";
$TLS_max_file_size_is = "Макс. размер файла";
$TLS_supported_file_formats = "Поддерживаемые форматы файлов";
</code-php>

==firstLogin.php==
<code-php>
$TLS_cant_create_user = "К сожалению, не удалось создать ваш логин. Пожалуйста, свяжитесь с администратором!";
$TLS_empty_email_address = " Пожалуйста, укажите e-mail!";
$TLS_empty_first_name = " Пожалуйста, укажите имя пользователя.";
$TLS_empty_last_name = " Пожалуйста, укажите фамилию.";
$TLS_fatal_page_title = "TestLink ::: Fatal Error";
$TLS_invalid_user_name = "Некорректный логин пользователя. Пожалуйста, придумайте другой.";
$TLS_passwd_dont_match = "Два введенных пароля не совпадают. Учтите, что пароли чувствительны к регистру, и попробуйте ещё раз.";
$TLS_user_cant_be_created_because = "Не удалось создать ваш аккаунт. Причина:";
$TLS_user_name_exists = "Этот логин пользователя уже используется. Пожалуйста, выберите другой.";
$TLS_valid_user_name_format = "Логин пользователя может состоять только из алфавитно-цифровых символов, пробелов, дефисов и подчеркиваний.";
$TLS_warning_empty_pwd = "Пожалуйста, укажите пароль. Пароль не может быть пустым.";
$TLS_your_info_please = "Введите информацию о пользователе";
</code-php>

==index.php==
<code-php>
$TLS_main_page_title = "TestLink::Главная страница";
</code-php>

==keywordsimport.php==
<code-php>
$TLS_please_choose_keywords_file = "Пожалуйста, выберите файл для загрузки";
$TLS_keywords_file = "Файл с ключевыми словами";
</code-php>

==lostPassword.php==
<code-php>
$TLS_bad_user = "Пользователь не найден, попробуйте еще";
$TLS_contact_admin = "<br> Если проблемы будут продолжаться, пожалуйста, свяжитесь с администратором системы.";
$TLS_mail_empty_address = "Вы не указали email-адреса в вашем профиле! Теперь, чтобы сбросить пароль вам нужно связаться с администратором TestLink-системы.";
$TLS_mail_passwd_subject = "Ваш новый пароль к TestLink'у.";
$TLS_mail_problems = "Ошибка в почтовых настройках, пожалуйста, свяжитесь с администратором.";
$TLS_page_title_lost_passwd = "TestLink - Утерян пароль";
$TLS_your_info_for_passwd = "Заполните информацию о вашем пользователе, и пароль будет вам выслан по почте.";
$TLS_your_password_is = "Ваш пароль к TestLink'у: <br>";
</code-php>

==login.php==
<code-php>
$TLS_bad_user_passwd = "Логин или пароль неверен. Попробуйте ещё!";
$TLS_login_msg_session_exists1 = "Ваша сессия в этом броузере ещё активна. Пожалуйста, используйте ";
$TLS_login_msg_session_exists2 = " если вы хотите обновить вашу сессию.";
$TLS_logout_link = "Выход";
$TLS_passwd_lost = "Ваш пароль выслан вам по email на адрес, который вы указали при регистрации. Проверьте вашу почту. В случае проблем, обратитесь к администратору вашего TestLink'а.";
$TLS_password_reseted="Новый пароль выслан вам по почте";
$TLS_please_login = "Пожалуйста, войдите в систему...";
$TLS_session_expired = "Время ваша сессии окончилось. Пожалуйста, войдите в систему заново.";
$TLS_your_first_login = "Добро пожаловать в TestLink! Сейчас у вас только гостевой доступ. Для большего, нужно войти в систему.";
</code-php>

==planPriority.php==
<code-php>
$TLS_high_priority = "Высокий";
$TLS_low_priority = "Низкий";
$TLS_medium_priority = "Средний";

$TLS_high_risk = "Высокий";
$TLS_low_risk = "Низкий";
$TLS_medium_risk = "Средний";

$TLS_high_importance = "Высокая";
$TLS_low_importance = "Низкая";
$TLS_medium_importance= "Средняя";
</code-php>

==tcEdit.php==
<code-php>
$TLS_tc_created = "Тест %s успешно создан";
$TLS_tc_deleted = "Тест %s успешно удален";
$TLS_tc_updated = "Тест %s отредактирован успешно";
$TLS_tc_update_failed = "Не удалась правка теста %s!";
</code-php>

==gui/templates/attachment404.tpl==
<code-php>
$TLS_btn_close = "Закрыть";
$TLS_error_attachment_not_found = "Ошибка: Вложение не найдено!";
$TLS_title_downloading_attachment = "Загружаем вложение";
</code-php>

==gui/templates/attachmentdelete.tpl==
<code-php>
$TLS_deleting_was_ok = "Вложение удалено.";
$TLS_error_attachment_delete = "При удалении вложения произошла ошибка!";
$TLS_title_delete_attachment = "Удалить вложение";
</code-php>

==gui/templates/containerDelete.tpl==
<code-php>
$TLS_btn_yes_del_comp = "Да, удалить группу тестов";
$TLS_container_title_testsuite =$TLS_test_suite;
$TLS_linked_but_not_executed="Связан с одним или более планом тестирования, но не выполнялась";
$TLS_question_del = "Действительно удалить";
$TLS_th_link_exec_status = "Статус исполнения и связей";
</code-php>

==gui/templates/containerNew.tpl==
<code-php>
$TLS_btn_create_testsuite = "Создать группу тестов";
$TLS_tc_keywords = "Ключевые слова";
$TLS_title_create = "Создать";
$TLS_warning_empty_testsuite_name = "Пожалуйста, задайте имя для группы тестов";
</code-php>

==gui/templates/bug_add.tpl==
<code-php>
$TLS_btn_add_bug = "Добавить баг";
$TLS_bug_id = "Bug id";
$TLS_button_enter_bug = "Создать новый баг";
$TLS_title_bug_add = "Добавить баг";
$TLS_link_bts_create_bug = "Доступ к системе регистрации багов";
</code-php>

==gui/templates/bug_delete.tpl==
<code-php>
$TLS_title_delete_bug = "Удалить баг";
</code-php>

==gui/templates/containerMove.tpl==
<code-php>
$TLS_btn_cp = "Копировать";
$TLS_btn_move = "Переместить";
$TLS_choose_target = "Выберите куда";
$TLS_cont_move_first = "Переместить это";
$TLS_cont_move_second = "в другое";
$TLS_copy_keywords = "Копировать ключевые слова";
$TLS_defined_exclam = "определен !";
$TLS_include_nested = "Включая вложенные данные (только для копирования).";
$TLS_sorry_further = "К сожалению, больше ничего нет ";
$TLS_title_move_cp = "Переместить/Скопировать";
</code-php>

==gui/templates/reqCreate.tpl==
<code-php>
$TLS_btn_cancel = "Отменить";
$TLS_btn_create = "Создать";
$TLS_help = "Помощь";
$TLS_req_create = "Создать требование";
$TLS_req_doc_id = "DOC-ID";
$TLS_req_spec = "Спецификация требований";
$TLS_reqs = "Требования";
$TLS_scope = "Описание";
$TLS_status = "Состояние";
$TLS_title = "Заголовок";
$TLS_warning_empty_req_title = "Заголовок требования должен быть не пуст!";
$TLS_warning_empty_reqdoc_id = "ID документа-требования не должен быть пуст!";
</code-php>

==gui/templates/containerOrder.tpl==
<code-php>
$TLS_btn_upd = "Обновить";
$TLS_no_nodes_to_reorder = "К сожалению, тут нечего упорядочивать.";
$TLS_node = "Имя";
$TLS_th_id = "ID";
$TLS_th_node_type = "Тест / Группа тестов";
$TLS_th_order = "Порядок";
$TLS_title_change_node_order = "Изменить порядок 'потомков'";
$TLS_node_type_dbtable_testsuites=$TLS_test_suite;
$TLS_node_type_dbtable_testcases=$TLS_testcase;
</code-php>

==gui/templates/containerView.tpl==
<code-php>
$TLS_alt_del_com = "Удалить эту группу тестов";
$TLS_alt_edit_com = "Править дату и заголовок для этой группы тестов";
$TLS_alt_move_cp_com = "Переместить или скопировать эту группу тестов в другой проект";
$TLS_btn_del_com = "Удалить";
$TLS_btn_edit_com = "Править";
$TLS_btn_export_all_testsuites = "Экспортировать все группы тестов";
$TLS_btn_export_tc = "Экспортировать тест(ы)";
$TLS_btn_export_testsuite = "Экспортировать группу тестов";
$TLS_btn_import_tc = "Импортировать тест(ы)";
$TLS_btn_import_testsuite = "Импортировать группу тестов";
$TLS_btn_move_cp_com = "Переместить/Копировать";
$TLS_btn_new_cat = "Новая группа тестов";
$TLS_btn_new_com = "Новая группа тестов";
$TLS_btn_new_tc = "Создать тест(ы)";
$TLS_btn_reorder_cat = "Переупорядочить потомков";
$TLS_edit_testproject_basic_data = "Править основные данные проекта";
$TLS_th_notes = "Описание";
$TLS_th_product_name = "Имя проекта";
</code-php>

==gui/templates/cfields_edit.tpl==
<code-php>
$TLS_available_on = "Доступно для";
$TLS_btn_add = "Добавить";
$TLS_btn_delete = "Удалить";
$TLS_btn_ok = "Ok";
$TLS_custom_field = "Пользовательское поле";
$TLS_enable_on_design = "Разрешить при <br>спецификации теста";
$TLS_enable_on_exec = "Разрешить при <br>прогоне теста";
$TLS_label = "Метка";
$TLS_name = "Имя";
$TLS_popup_delete_custom_field = "Вы уверены, что хотите удалить пользовательское поле?";
$TLS_possible_values = "Возможные значения";
$TLS_show_on_design = "Показывать при <br>спецификации теста";
$TLS_show_on_exec = "Показывать при <br>прогоне теста";
$TLS_testcase = $TLS_test_case;
$TLS_title_cfields_mgmt = "Пользовательские поля";
$TLS_type = "Тип";
$TLS_warning_empty_cfield_label = "Пожалуйста, введите метку для этого пользовательского поля.";
$TLS_warning_empty_cfield_name = "Пожалуйста, введите имя этого пользовательского поля.";
</code-php>

==gui/templates/inc_update.tpl==
<code-php>
$TLS_info_failed_db_upd = "Не удалось обновить базу данных!";
$TLS_info_failed_db_upd_details = "Не удалось обновить базу данных! - Подробности:";
$TLS_invalid_query = "Ошибка:";
$TLS_warning = "Предупреждение!!";
$TLS_was_success = " был(и) успешно ";
</code-php>

==gui/templates/execNavigator.tpl==
<code-php>
$TLS_TestPlan = "План тестирования";
$TLS_btn_apply_filter = "Применить фильтр";
$TLS_btn_update_menu = "Обновить меню";
$TLS_caption_nav_filter_settings = "Параметры выборки";
$TLS_current_build = "Текущая сборка";
$TLS_filter_owner = "Ответственный";
$TLS_filter_result = "Результат";
$TLS_filter_tcID = "Фильтр: ID теста";
$TLS_keyword = "Ключевое слово";
$TLS_test_status_all_status="Все";
</code-php>

==gui/templates/mainPage.tpl==
<code-php>
$TLS_th_my_perc_completed = "У меня выполнено [%]";
$TLS_th_name = "Имя";
$TLS_th_perc_completed = "Выполнено [%]";
$TLS_title_your_tp_metrics = "Ваши метрики для плана тестирования";
</code-php>

==gui/templates/newest_tcversions.tpl==
<code-php>
$TLS_linked_version = "Связанная версия";
$TLS_newest_version = "Самая новая из доступных активных версий";
$TLS_title_newest_tcversions = "Самые новые версии связанных тестов";
</code-php>

==gui/templates/emailSent.tpl==
<code-php>
$TLS_send_test_report = "- Послать тест-отчёт";
</code-php>

==gui/templates/reqImport.tpl==
<code-php>
$TLS_Result = "Результат";
$TLS_Title = "Заголовок";
$TLS_btn_back2srs = "Назад, к спецификации требований";
$TLS_btn_import = "Импорт";
$TLS_btn_upload_file = "Загрузить файл";
$TLS_check_req_file_structure = "Пожалуйста, проверьте формат файла. Не получается получить из этого файла требования";
$TLS_local_file = "Файл:";
$TLS_max_size_cvs_file1 = "Максимальный размер для этого файла";
$TLS_max_size_cvs_file2 = "kB";
$TLS_req_import_check_note = "Пожалуйста, разрешите возможные конфликты и запустите процесс импорта.";
$TLS_req_import_dont_empty = "Не импортируйте элементы с пустой Сферой";
$TLS_req_import_option_double = "Добавить ещё с тем же заголовком";
$TLS_req_import_option_header = "Разрешить конфликт";
$TLS_req_import_option_overwrite = "Обновить существующий";
$TLS_req_import_option_skip = "Пропускать импорт дублирующих требований";
$TLS_req_import_type = "Тип:";
$TLS_req_msg_norequirement = "Нет требований";
$TLS_required_cvs_format = "Формат файла с требованиями:";
$TLS_title_choose_file_type = "Выберите тип файла";
$TLS_title_choose_local_file = "Выберите файл для загрузки";
$TLS_title_req_import = "Загрузка требований";
$TLS_title_req_import_check_input = "Проверьте импортируемые данные";
</code-php>

==gui/templates/inc_attachments.tpl==
<code-php>
$TLS_alt_delete_build = "Удалить эту сборку";
$TLS_alt_delete_attachment = "Удалить это вложение";
$TLS_attached_files = "Вложенные файлы";
$TLS_attachment_feature_disabled = "вложения отключены";
$TLS_button_upload = "Загрузить";
$TLS_upload_file_new_file = "Загрузить новый файл";
$TLS_warning_delete_attachment = "Действительно удалить вложение?";
</code-php>

==gui/templates/resultsNavigator.tpl==
<code-php>
$TLS_btn_print = "Печать";
$TLS_note_email_sent_t = "Примечание: email format послан на email пользователя";
$TLS_send_results = "Послать отчеты";
$TLS_send_to = "To:";
$TLS_subject = "Subject:";
$TLS_title_active_build = "Активная сборка";
$TLS_title_report_type = "Формат отчета";
$TLS_via_email = "через eMail";
</code-php>

==gui/templates/inc_attachments_upload.tpl==

==gui/templates/cfields_view.tpl==
<code-php>
$TLS_btn_cfields_create = "Создать";
$TLS_manage_cfield = "Управлять пользовательскими полями";
</code-php>

==gui/templates/inc_cat_viewer_ro_m0.tpl==
<code-php>
$TLS_cat_scope = "Описание";
$TLS_category = "Группа тестов";
$TLS_configuration = "Конфигурация";
$TLS_data = "Данные";
$TLS_not_defined = "Не определено.";
$TLS_tools = "Инструменты";
</code-php>

==gui/templates/inc_cat_viewer_rw.tpl==
<code-php>
$TLS_cat_alt_name = "Обязательно заполнить имя группы тестов.";
$TLS_cat_config = "Конфигурация";
$TLS_cat_data = "Данные";
$TLS_cat_name = "Имя группы тестов";
$TLS_cat_tools = "Инструменты";
</code-php>

==gui/templates/reqEdit.tpl==
<code-php>
$TLS_btn_update = "Обновить";
$TLS_by = "by";
$TLS_coverage = "Покрытие";
$TLS_popup_delete_req = "Удалить это требование, Вы уверены?";
$TLS_req_edit = "Править требование";
$TLS_req_msg_notestcase = "Связанных тестов нет.";
$TLS_requirement_spec = "Спецификация требования";
$TLS_test_case_id = "ID";
$TLS_title_created = "Создано:";
$TLS_title_last_mod = "Последняя правка:";
</code-php>

==gui/templates/buildNew.tpl==
<code-php>
$TLS_active = "Активная";
$TLS_enter_build = "Заголовок";
$TLS_enter_build_notes = "Описание";
$TLS_msg_build = "Замечание: Каждая сборка относится к активному плану тестирования. Описание должно включать: список развертываемых пакетов, утверждений, состояние, и т.п.";
$TLS_open = "Открыть";
$TLS_test_plan = "План тестирования";
$TLS_title_build_2 = "Управление сборками";
$TLS_title_build_create = "Создать новую Сборку";
$TLS_title_build_update = "Править Сборку";
$TLS_warning_empty_build_name = "Пожалуйста, введите имя для этой Сборки!";
</code-php>

==gui/templates/inc_comp_viewer_ro.tpl==
<code-php>
$TLS_component = "Группа тестов";
$TLS_introduction = "Введение";
$TLS_limitations = "Ограничения";
$TLS_methodology = "Методология";
$TLS_references = "Ссылки";
</code-php>

==gui/templates/inc_comp_viewer_rw.tpl==
<code-php>
$TLS_comp_alt_name = "Обязательно введите имя группы тестов.";
$TLS_comp_intro = "Введение";
$TLS_comp_lim = "Ограничения";
$TLS_comp_method = "Методология";
$TLS_comp_name = "Имя группы тестов";
$TLS_comp_ref = "Ссылки";
$TLS_comp_scope = "Описание";
</code-php>

==gui/templates/reqSpecView.tpl==
<code-php>
$TLS_btn_analyse = "Анализировать";
$TLS_btn_check_all = "Проверить все";
$TLS_btn_delete_spec = "Удалить спецификацию";
$TLS_btn_edit_spec = "Править спецификацию";
$TLS_btn_export_reqs = "Экспортировать требования";
$TLS_btn_req_create = "Создать новое требование";
$TLS_btn_spec_list = "Список спецификаций";
$TLS_btn_uncheck_all = "Убрать все отметки";
$TLS_cant_delete_req_nothing_sel = "Пожалуйста, выберите требование!";
$TLS_popup_sure_delete = "Вы уверены удалить эту спецификацию требования?";
$TLS_req_select_create_tc = "Создать тесты";
$TLS_req_select_delete = "Удалить требования";
$TLS_req_title_list = "Список требований";
$TLS_req_total = "Всего треб.";
$TLS_req_reorder = "Переупорядочить требования?";
$TLS_warning_delete_requirements = "Вы уверены удалить выбранные требования?";
$TLS_title_change_req_order = "Переупорядочивание требований";
</code-php>

==gui/templates/inc_copyrightnotice.tpl==
<code-php>
$TLS_gnu_gpl = "GNU GPL";
$TLS_lic_home = "Домой";
$TLS_lic_product = "TestLink project";
$TLS_licensed_under = "TestLink лицензируется согласно ";
</code-php>

==gui/templates/containerEdit.tpl==
<code-php>
$TLS_btn_update_testsuite = "Обновить группу тестов";
$TLS_title_edit_level = "Править";
</code-php>

==gui/templates/reqSpecAnalyse.tpl==
<code-php>
$TLS_edit = "Править";
$TLS_none = "Пусто ";
$TLS_req = "Требования";
$TLS_req_spec_change = "Изменить спецификацию требований на ";
$TLS_req_title_analyse = "Анализировать спецификацию требований ";
$TLS_req_title_covered = "Покрытые требования";
$TLS_req_title_in_tl = "Требований, зарегистрированных в TestLink";
$TLS_req_title_nottestable = "Нетестируемые требования";
$TLS_req_title_uncovered = "Непокрытые требования";
$TLS_req_title_not_in_tl = "Требований, отсутствующих в TestLink";
$TLS_req_total_count = "Всего требований";
$TLS_testcases = "Тесты";
</code-php>

==gui/templates/reqSpecCreate.tpl==
<code-php>
$TLS_action_create_srs = "Создать спецификацию требований";
$TLS_testproject = "проект";
</code-php>

==gui/templates/inc_reqView.tpl==
<code-php>
$TLS_Author = "Автор";
$TLS_last_edit = "Последняя правка: ";
</code-php>

==gui/templates/inc_res_by_comp.tpl==
<code-php>
$TLS_title_res_by_top_level_suites = "Результаты топовых групп тестов";
$TLS_trep_blocked = "Блокировано";
$TLS_trep_comp = "Группа тестов";
$TLS_trep_comp_perc = "Выполнена [%]";
$TLS_trep_failed = "Сбой";
$TLS_trep_not_run = "Не запускали";
$TLS_trep_passed = "Выполнено";
$TLS_trep_total = "Всего";
</code-php>

==gui/templates/inc_res_by_keyw.tpl==
<code-php>
$TLS_title_res_by_kw = "Результаты по ключевому слову";
$TLS_trep_kw = "Ключевое слово";
</code-php>

==gui/templates/inc_res_by_owner.tpl==
<code-php>
$TLS_title_res_by_owner = "Результаты по тестировщику";
$TLS_trep_owner = "Тестировщик";
$TLS_title_res_by_tester = "Результаты по тестировщику";
$TLS_trep_tester = "Тестировщик";
</code-php>

==gui/templates/inc_res_by_prio.tpl==
<code-php>
$TLS_tit_end_date = "Дата окончания";
$TLS_tit_milestone = "Веха";
$TLS_title_res_by_prio = "Результаты по приоритету";
$TLS_trep_milestone_goal = "Цель вехи [%]";
$TLS_trep_prio = "Приоритет";
$TLS_trep_status = "Состояние";
</code-php>

==gui/templates/inc_res_by_ts.tpl==
<code-php>
$TLS_title_res_by_ts = "Результаты по группе тестов";
$TLS_trep_imp = "Важность";
$TLS_trep_risk = "Риск";
$TLS_trep_ts = "Группа тестов";
</code-php>

==gui/templates/reqSpecEdit.tpl==

==gui/templates/inc_show_bug_table.tpl==
<code-php>
$TLS_build = "Сборка";
$TLS_caption_bugtable = "Связанные баги";
$TLS_delete_bug="Удалить баг";
$TLS_del_bug_warning_msg = "Действительно удалить этот баг?";
</code-php>

==gui/templates/reqSpecList.tpl==
<code-php>
$TLS_btn_assign_tc = "Указать тест";
$TLS_no_docs = "Нет доступных документов.";
$TLS_req_list_docs = "Спецификации требований";
</code-php>

==gui/templates/tcEdit_New_viewer.tpl==
<code-php>
$TLS_alt_add_tc_name = "Обязательно укажите имя теста.";
$TLS_expected_results = "Ожидаемые результаты";
$TLS_steps = "Шаги";
$TLS_summary = "Резюме";
$TLS_tc_title = "Заголовок тест-кейса";
</code-php>

==gui/templates/show_exec_notes.tpl==
<code-php>
$TLS_title_execution_notes = "Замечания по выполнению";
</code-php>

==gui/templates/rolesedit.tpl==
<code-php>
$TLS_btn_create_role = "Создать";
$TLS_btn_edit_role = "Править";
$TLS_caption_define_role = "Определить роль";
$TLS_caption_possible_affected_users = "Возможно влияет на следующих пользователей";
$TLS_enter_role_notes = "Введите описание роли";
$TLS_menu_assign_product_roles = "Укажите роли проекта";
$TLS_menu_assign_testplan_roles = "Укажите роли для плана тестирования";
$TLS_menu_define_roles = "Новая роль";
$TLS_menu_mod_user = "Править пользователя";
$TLS_menu_new_user = "Новый пользователь";
$TLS_menu_edit_user = "Редактировать пользователя";
$TLS_menu_view_users = "Список пользователей";
$TLS_menu_view_roles = "Просмотр ролей";
$TLS_th_cf_rights = "Права на пользовательские поля";
$TLS_th_kw_rights = "Права на ключевые слова";
$TLS_th_mgttc_rights = "Права на управление тест-кейсами";
$TLS_th_product_rights = "Права на проект";
$TLS_th_req_rights = "Права на требование";
$TLS_th_rights = "Разрешения";
$TLS_th_rolename = "Роль";
$TLS_th_tp_rights = "Права на план тестирования";
$TLS_th_user_rights = "Права пользователей";
$TLS_title_user_mgmt = "Управление пользователями";
$TLS_warning_modify_role = "Действительно исправить роль?";
</code-php>

==gui/templates/tcSearchForm.tpl==
<code-php>
$TLS_btn_find = "Найти";
$TLS_caption_search_form = "Искать тесты";
$TLS_not_applied = "Не применимо";
$TLS_th_tcid = "ID теста";
$TLS_th_tcversion = "Версия";
$TLS_th_title = "Заголовок";
$TLS_title_search_tcs = "Поиск";
</code-php>

==gui/templates/infoWindow.tpl==

==gui/templates/tcDelete.tpl==
<code-php>
$TLS_btn_yes_iw2del = "Да, удалите тест!";
$TLS_question_del_tc = "Действительно удалить тест?";
$TLS_th_executed = "Выполнено";
$TLS_th_linked_to_tplan = "Связан с планом тестирования";
$TLS_th_version = "Версия";
</code-php>

==gui/templates/tcNew.tpl==
<code-php>
$TLS_title_new_tc = "Создать тест";
$TLS_warning_empty_tc_title = "Пожалуйста, задайте заголовок для теста";
</code-php>

==gui/templates/tcImport.tpl==
<code-php>
$TLS_title_imp_tc_data = "Импорт данных для теста";
</code-php>

==gui/templates/keywordsimport.tpl==
<code-php>
$TLS_title_keyword_import_to = "Импортировать ключевые слова в ";
$TLS_title_keyword_import = "Импорт ключевых слов";
</code-php>

==gui/templates/keywordsexport.tpl==
<code-php>
$TLS_btn_export = "Экспорт";
$TLS_title_req_import_to = "Импортировать требования в документ:";
</code-php>

==gui/templates/cfields_tproject_assign.tpl==
<code-php>
$TLS_btn_assign = "Привязать";
$TLS_btn_cfields_active_mgmt = "Обновить активное состояние";
$TLS_btn_cfields_display_order = "Сохранить порядок показа";
$TLS_btn_unassign = "Освободить от";
$TLS_cfields_active = "Активный";
$TLS_cfields_tproject_assign = "Привязать пользовательские поля";
$TLS_display_order = "Порядок показа";
$TLS_title_assigned_cfields = "Привязанные пользовательские поля";
$TLS_title_available_cfields = "Доступные пользовательские поля";
</code-php>

==gui/templates/usersview.tpl==
<code-php>
$TLS_No = "Нет";
$TLS_Yes = "Да";
$TLS_alt_delete_user = "Действительно удалить выбранного пользователя?";
$TLS_alt_edit_user = "Править пользователя";
$TLS_order_by_login = "По порядку логинов";
$TLS_order_by_role_descr = "По порядку описания ролей";
$TLS_th_active = "Активный";
$TLS_th_delete = "Удалить?";
$TLS_th_email = "Email";
$TLS_th_first_name = "Имя";
$TLS_th_last_name = "Фамилия";
$TLS_th_locale = "Локализация";
$TLS_th_login = "Логин";
$TLS_th_role = "Роль";
$TLS_warning_delete_user = "Действительно удалить выбранного пользователя?";
</code-php>

==gui/templates/login.tpl==
<code-php>
$TLS_btn_login = "Войти";
$TLS_login_name = "Логин:";
$TLS_lost_password_q = "Забыли пароль?";
$TLS_new_user_q = "Новый пользователь?";
$TLS_password = "Пароль:";
</code-php>

==gui/templates/loginFirst.tpl==
<code-php>
$TLS_btn_add_user_data = "Добавить пользовательские данные";
$TLS_e_mail = "E-mail (нужен, чтобы получить новый пароль):";
$TLS_first_name = "Имя:";
$TLS_last_name = "Фамилия:";
$TLS_link_back_to_login = "Войти еще раз";
$TLS_password_again = "Повторите пароль:";
$TLS_password_mgmt_is_external = "Используется внешнее управление паролями";
</code-php>

==gui/templates/tcMove.tpl==
<code-php>
$TLS_btn_mv = "Переместить";
$TLS_choose_cat = "Выберите группу тестов";
$TLS_inst_move = "Переместить этот тест в другую группу тестов (внутри того же плана тестирования).";
$TLS_title_mv_cp_tc = "Переместить/Копировать тест";
</code-php>

==gui/templates/loginLost.tpl==
<code-php>
$TLS_btn_send = "Выслать пароль";
$TLS_password_reset = "Сбросить пароль";
</code-php>

==gui/templates/tcView.tpl==
<code-php>
$TLS_no_records_found = "Ничего не найдено.";
</code-php>

==gui/templates/execSetResults.tpl==
<code-php>
$TLS_alt_attachment_mgmt = "вложения";
$TLS_alt_notes = "заметки";
$TLS_attachment_mgmt = "вложения";
$TLS_btn_history_off = "Показывать только последний прогон";
$TLS_btn_history_on = "Показывать полную историю прогонов";
$TLS_btn_save_all_tests_results = "Сохранить все результаты прогонов";
$TLS_btn_save_tc_exec_results = "Сохранить результат прогона";
$TLS_bug_mgmt = "Управление багами";
$TLS_build_is_closed = "Сборка закрыта";
$TLS_builds_notes = "Описание сборки";
$TLS_bulk_tc_status_management = "Массовое управление состоянием тестов";
$TLS_date_time_run = "Дата";
$TLS_details = "Подробности";
$TLS_exec_notes = "Заметки";
$TLS_exec_status = "Состояние";
$TLS_execution_history = "История прогонов";
$TLS_img_title_bug_mgmt = "Управление багами";
$TLS_img_title_delete_execution= "Удалить прогон";
$TLS_just_last_execution_for_this_build = "Последний прогон для этой сборки";
$TLS_no_data_available = "Данные отсутствуют";
$TLS_set_all_tc_to = "Установить всем состояние ";
$TLS_show_hide = "Показать / скрыть";
$TLS_tc_not_tested_yet = "Еще не протестировано:";
$TLS_test_cases_cannot_be_executed = "Тесты не могут быть выполнены";
$TLS_test_exec_by = "Протестировано: ";
$TLS_test_exec_expected_r = "Ожидаемые результаты";
$TLS_test_exec_last_run_date = "Самые последние запуски:";
$TLS_test_exec_notes = "Заметки / Описание";
$TLS_test_exec_on_build = " в Сборке";
$TLS_test_exec_result = "Результат";
$TLS_test_exec_steps = "Шаги";
$TLS_test_exec_summary = "Резюме";
$TLS_test_plan_notes = "Заметки по плану тестирования";
$TLS_test_status_not_run = "Не запущен";
$TLS_th_test_case_id = "ID ";
$TLS_th_testsuite = "Группа тестов";
$TLS_title_t_r_on_build = "Результы тестов по Сборке";
$TLS_title_t_r_owner = " Ответственный:";
$TLS_title_test_case = "Тест";
$TLS_version = "Версия";
</code-php>

==gui/templates/inc_testsuite_viewer_ro.tpl==
<code-php>
$TLS_keywords = "Ключевые слова";
$TLS_test_suite = "Группа тестов";
</code-php>

==gui/templates/navBar.tpl==
<code-php>
$TLS_home = "Домой";
$TLS_link_logout = "Выход";
$TLS_product = "Проект";
$TLS_product_role = "Роль проекта";
$TLS_title_edit_personal_data = "Мой профиль";
$TLS_title_execute = "Выполнить";
$TLS_title_results = "Отчеты";
$TLS_title_specification = "Спецификация";
</code-php>

==gui/templates/inc_testsuite_viewer_rw.tpl==

==gui/templates/planAddTC_m1.tpl==
<code-php>
$TLS_add_tc = "Добавить";
$TLS_add_remove_selected_tc_hint = "Операция будет выполнена над ВСЕМИ группами тестов";
$TLS_btn_add_remove_selected_tc = "Добавить / Удалить выбранное";
$TLS_btn_add_selected_tc = "Добавить выбранное";
$TLS_btn_check = "Отметить";
$TLS_btn_uncheck = "Снять отметки";
$TLS_check_uncheck_tc = "Все тесты в этой группе тестов.";
$TLS_check_uncheck_all_checkboxes="отметить все/снять все отметки";
$TLS_has_been_executed = "были выполнены";
$TLS_inactive_testcase = "неактивны";
$TLS_no_testcase_available = "Тестов нет";
$TLS_note_keyword_filter = "Тесты фильтруются по ключевому слову";
$TLS_remove_tc = "Удалить";
$TLS_th_test_case = "Тест";
$TLS_title_add_remove_test_to_plan = "Добавить/Удалить тест(ы) в/из плана тестирования";
$TLS_title_add_test_to_plan = "Добавить тесты в план тестирования";
$TLS_warning_add_remove_selected_tc = "Вы уверены удалить выбранные тесты из этого плана тестирования?";
</code-php>

==gui/templates/planAddTCNavigator.tpl==
<code-php>
$TLS_title_navigator = "Навигатор";
</code-php>

==gui/templates/planPriority.tpl==
<code-php>
$TLS_btn_upd_prio = "Сохранить";
$TLS_title_priority = "Определить приоритеты для плана тестирования";
$TLS_tr_th_importance = "Важность";
$TLS_tr_th_prio_cba = "Приоритет (C/B/A)";
$TLS_tr_th_risk = "Риск/Важность";
</code-php>

==gui/templates/planEdit.tpl==
<code-php>
$TLS_btn_testplan_create = "Создать";
$TLS_cancel = "Отменить";
$TLS_opt_no = "Нет";
$TLS_testplan_question_create_tp_from = "Создать из существующего плана тестирования?";
$TLS_testplan_th_active = "Активный";
$TLS_testplan_th_name = "Имя";
$TLS_testplan_th_notes = "Описание";
$TLS_testplan_title_create = "Создать новый план тестирования";
$TLS_testplan_title_edit = "Править план тестирования";
$TLS_testplan_title_for_project = "для проекта: ";
$TLS_testplan_title_tp_management = "Управление планами тестирования";
$TLS_testplan_txt_notes = <<<END
План тестирования должен содержать ясно определенные задачи, включая временные границы.
Он может содержать тест-активность для выпускаемой версии продукта (включая патчи)
или просто единственный запрос от пользователя.<br/>
В описании можно ссылаться на план и другую документацию по проекту.
Разумно перечислить тестируемые возможности, риски и т.п.<br/>
Можно создать новый план тестирования из существующего ("клонировать").
Будут скопированы следующие элементы: сборки, тесты, приоритеты,
Вехи и роли пользователей.<br/>
План тестирования можно деактивировать/заморозить: т.е. запретить любое изменение
атрибутов или вложенных элементов плана тестирования.
Такие планы тестирования будут видны только на странице отчетов и на этой странице.
END;

$TLS_warning_empty_tp_name = "Пожалуйста, введите имя плана тестирования.";
</code-php>

==gui/templates/planNew.tpl==
<code-php>
$TLS_testplan_btn_edit = "Сохранить";
$TLS_testplan_btn_new = "Создать";
$TLS_testplan_menu_create = "Создать";
$TLS_testplan_menu_edit = "Править";
$TLS_testplan_menu_list = "Список";
</code-php>

==gui/templates/planMilestones.tpl==
<code-php>
$TLS_alt_delete_milestone = "Удалить веху?";
$TLS_btn_edit_milestone = "Править";
$TLS_btn_new_milestone = "Создать";
$TLS_info_milestones_date = "Веха не может иметь дату раньше чем 'сегодня'";
$TLS_no_milestones = "Для этого плана тестирования вехи не определены.";
$TLS_popup_delete_milestones = "Вы уверены удалить веху %NAME% ?";
$TLS_warning_empty_milestone_name="Укажите имя вехи!";

$TLS_th_date_format = "Целевая Дата";
$TLS_th_perc_a_prio = "% A-приоритет";
$TLS_th_perc_b_prio = "% B-приоритет";
$TLS_th_perc_c_prio = "% C-приоритет";
$TLS_title_existing_milestones = "Существующие вехи";
$TLS_title_milestones = "Вехи для плана тестирования";
$TLS_title_new_milestone = "Новая Веха";
</code-php>

==gui/templates/projectedit.tpl==
<code-php>
$TLS_btn_activate = "Активировать";
$TLS_btn_del = "Удалить";
$TLS_btn_edit_del = "Править / Удалить";
$TLS_btn_inactivate = "Деактивировать";
$TLS_caption_edit_product = "Править проект";
$TLS_caption_new_product = "Создать проект";
$TLS_color = "Цвет";
$TLS_enable_requirements = "Включить функциональность Требований";
$TLS_info_failed_loc_prod = "Не удалось локализовать проект.";
$TLS_notes = "Заметки";
// Warning!!! - if JS string you must use \\n to get \n
$TLS_popup_product_delete = <<<END
Внимание! Вы собираетесь необратимо удалить все данные связанные проектом:
результаты тестов, планы тестирования, тесты и т.п. \\n
Вместо удаления вы можете деактивировать проект. \\n
Если вы всё-таки настроены удалить проект, рекомендуем вам сначала
сделать бэкап базы данных. \\n
Итак, вы по прежнему уверены удалить проект?
END;
$TLS_warning_empty_tproject_name = "Обязательно задайте имя проекта!";
</code-php>

==gui/templates/reqAssign.tpl==
<code-php>
$TLS_please_select_a_req = "Пожалуйста, выберите требование";
$TLS_req_msg_norequirement66 = "Требования нет";
$TLS_req_title_assign = "Привяжите требования к тесту";
$TLS_req_title_assigned = "Привязанные требования";
$TLS_req_title_unassigned = "Доступные требования";
$TLS_warning_req_tc_assignment_impossible = <<<END
<p>
Вы <b>не можете</b> делать привязку по одной из следующих причин:
<ul>
<li>Не определено ни одной спецификации требования;
<li>Спецификации требований пусты.
</ul>
END;
</code-php>

==gui/templates/tcEdit.tpl==
<code-php>
$TLS_title_edit_tc = "Править тест";
$TLS_warning_editing_executed_tc = "Внимание: Этот версия теста уже выполнялась";
</code-php>

==gui/templates/planOwner.tpl==
<code-php>
$TLS_assign_ownership = "Назначить ответственного";
$TLS_def_prio_rules = "Определить правила приоритетов";
$TLS_opt_label_none = "нет";
$TLS_th_imp = "Важность";
$TLS_th_owner = "Тестировщик";
$TLS_th_risk = "Риск";
$TLS_th_test_suite = "Группа тестов";
$TLS_title_plan_ownership = "Владелец плана тестирования";
</code-php>

==gui/templates/tcView_viewer.tpl==
<code-php>
$TLS_activate_this_tcversion = "Активировать эту версию";
$TLS_Requirements = "Требования";
$TLS_btn_del_this_version = "Удалить эту версию";
$TLS_btn_edit = "Править";
$TLS_btn_mv_cp = "Переместить/Копировать";
$TLS_btn_new_version = "Создать новую версию";
$TLS_can_not_edit_tc = "Вы не можете редактировать эту версию, т.к. она уже выполнялась";
$TLS_deactivate_this_tcversion = "Деактивировать эту версию";
$TLS_tcversion_is_inactive_msg = "Эта версия <b>неактивна</b>, и не будет доступна для включения в план тестирования";
</code-php>

==gui/templates/planRemoveTC_m1.tpl==
<code-php>
$TLS_btn_remove_selected_tc = "Удалить выбранные тесты tcs";
$TLS_remove_ok = "Удаление прошло успешно ok";
$TLS_title_remove_test_from_plan = "Удалить тест из плана тестирования";
</code-php>

==gui/templates/planTesters.tpl==
<code-php>
$TLS_btn_save = "Сохранить";
</code-php>

==gui/templates/keywordsAssign.tpl==
<code-php>
$TLS_keyword_assignment_empty_tsuite = "В этой группе тестов нет тестов => ключевое слово привязать нельзя";
$TLS_menu_assign_kw_to_tc = "Привязать к тестам";
$TLS_menu_manage_keywords = "Управление ключевыми словами";
$TLS_title_keywords = "Ключевые слова";
</code-php>

==gui/templates/planTestersNavigator.tpl==
<code-php>
$TLS_label_list_of = "Список ";
$TLS_opt_test_plans = "планов тестирования";
$TLS_opt_users = "пользователей";
</code-php>

==gui/templates/planUpdateTC.tpl==
<code-php>
$TLS_btn_upd_ck_tc = "Изменить выбранные тест(ы)";
$TLS_info_all_tc_uptodate = "Все тесты актуальны.";
$TLS_th_category = "Группа тестов";
$TLS_th_component = "Группа тестов";
$TLS_th_id_tc = "[ID] теста";
$TLS_th_reason = "Причина правки";
$TLS_th_spec_version = "Специальная версия";
$TLS_th_status = "Состояние";
$TLS_th_suite_version = "Версия группы тестов";
$TLS_th_update = "Изменить";
$TLS_title_upd_mod_tc = "Изменить исправленные тесты в ";
</code-php>

==gui/templates/keywordsView.tpl==
<code-php>
$TLS_alt_delete_keyword = "Удалить ключевое слово?";
$TLS_btn_create_keyword = "Создать ключевое слово";
$TLS_btn_edit_keyword = "Править";
$TLS_btn_import_keywords = "Импорт";
$TLS_th_keyword = "Ключевое слово";
$TLS_warning_delete_keyword = "Вы уверены удалить ключевое слово?";
$TLS_warning_enter_at_least1 = "Пожалуйста, введите хотя бы ";
$TLS_warning_enter_at_least2 = " символов.";
$TLS_warning_enter_less1 = "Пожалуйста, используйте не больше чем";
$TLS_warning_enter_less2 = " символов.";
</code-php>

==gui/templates/reqexport.tpl==
<code-php>
$TLS_title_req_export_to = "Экспорт требований";
</code-php>

==gui/templates/resultsAllBuilds.tpl==
<code-php>
$TLS_test_status_blocked = "Блокирован";
$TLS_test_status_failed = "Сбой";
$TLS_test_status_passed = "Пройден";
$TLS_th_build = "Сборка";
$TLS_th_tc_total = "Всего тестов";
</code-php>

==gui/templates/resultsBugs.tpl==
<code-php>
$TLS_date = "Дата:";
$TLS_printed_by = "Напечатано:";
$TLS_title_test_case_bugs = "Баги по тесту";
$TLS_title_test_case_timestamp = "Временная метка теста";
$TLS_title_test_case_title = "Заголовок теста";
$TLS_title_test_suite_name = "Имя группы тестов";
</code-php>

==gui/templates/resultsBuild.tpl==
<code-php>
$TLS_title_met_of_build = "Метрики сборки";
</code-php>

==gui/templates/resultsByStatus.tpl==
<code-php>
$TLS_info_test_results = <<<END
<p>
Показываются результаты только последнего теста.
<p>
В частности, тесты скрыты, если результаты тестов для следующей сборки
имеют статус отличный от "в процессе".
END;

$TLS_th_bugs = "Баги";
$TLS_th_date = "Дата";
$TLS_th_run_by = "Запустил:";
</code-php>

==gui/templates/resultsGeneral.tpl==
<code-php>
$TLS_title_gen_test_rep = "Общие метрики плана тестирования";
</code-php>

==gui/templates/resultsMoreBuilds_query_form.tpl==
<code-php>
$TLS_excel_format = "MS Excel";
$TLS_html_format = "HTML";
$TLS_last_status_any = "Любой";
$TLS_last_status_blocked = "Блокирован";
$TLS_last_status_failed = "Сбой";
$TLS_last_status_not_run = "Не стартовал";
$TLS_last_status_passed = "Пройден";
$TLS_select_builds_header = "Выберите сборку(и)";
$TLS_select_components_header = "Выберите группу тестов";
$TLS_select_keyword_header = "Выберите ключевое слово";
$TLS_select_last_result_header = "Выберите последний результат";
$TLS_select_owner_header = "Выберите владельца";
$TLS_select_report_format_header = "Выберите формат отчета";
$TLS_submit_query = "Выполнить запрос";
$TLS_test_plan_header = "План тестирования: ";
$TLS_query_metrics_report = "Запросить отчет по метрикам";
$TLS_enter_start_time = "Введите начальное время";
$TLS_enter_end_time = "Введите конечное время";
$TLS_year = "год";
$TLS_month = "месяц";
$TLS_day = "день";
$TLS_hour = "час";
$TLS_search_in_notes = "поиск строки в заметках";
$TLS_executor = "исполнитель";
</code-php>

==gui/templates/resultsMoreBuilds_report.tpl==
<code-php>
$TLS_caption_show_collapse = "Показать/Свернуть";
$TLS_caption_user_selected_query_parameters = "Параметры запроса";
$TLS_not_yet_executed = "Еще не выполнялся";
$TLS_show_hide_all = "Показать/Скрыть все";
$TLS_th_builds = "Сборка(и)";
$TLS_th_execution_ts = "Время";
$TLS_th_last_result = "Последний результат";
$TLS_th_report_format = "Тип отчета";
$TLS_th_test_plan = "План тестирования";
$TLS_th_test_suites = "Группа(ы) тестов";
$TLS_th_tester_id = "Тестировщик";
$TLS_th_total_block = "# блокированных ";
$TLS_th_total_cases = "# тестов";
$TLS_th_total_fail = "# сбоев";
$TLS_th_total_not_run = "# не стартовавших";
$TLS_th_total_pass = "# выполненных";
$TLS_th_start_time = "Время начала";
$TLS_th_end_time = "Время окончания";
$TLS_th_executor = "Исполнитель";
$TLS_th_search_notes_string = "в заметках искать строку";
$TLS_true = "да";
$TLS_false = "нет";
$TLS_display_suite_summaries = "Показать итоги по группе тестов";
$TLS_display_query_params = "Показать параметры запроса";
$TLS_display_totals = "Показать суммарную информацию";
</code-php>

==gui/templates/resultsReqs.tpl==
<code-php>
$TLS_req_title_blocked = "Заблокировано требований";
$TLS_req_title_failed = "Нарушено требований";
$TLS_req_title_notrun = "Непроверенных требований";
$TLS_req_title_passed = "Выполнено требований";
$TLS_title_result_req_testplan = "Результаты тестов основанных на спецификации требований";
$TLS_title_test_plan = "План тестирования";
</code-php>

==gui/templates/resultsSend.tpl==
<code-php>
$TLS_btn_send_report = "Послать отчет";
$TLS_check_send_to_me = "Послать отчет самому себе";
$TLS_mail_body = "Тело письма:";
$TLS_mail_report = "Отчет:";
$TLS_mail_subject = "Тема письма:";
$TLS_mail_to = "Кому:";
$TLS_status_for_build = "Состояние сборки";
$TLS_tp_status = "Общее состояние плана тестирования";
$TLS_tp_status_for_build = "Состояние плана тестирования для сборки";
</code-php>

==gui/templates/resultsTC.tpl==
<code-php>
$TLS_generated_by_TestLink_on="Сформировано системой TestLink, ";
</code-php>

==gui/templates/tcEdit_m2.tpl==

==gui/templates/tcPrintNavigator.tpl==
<code-php>
$TLS_caption_print_opt = "Настройки печати";
$TLS_tr_td_show_as = "Показать как";
</code-php>

==gui/templates/tcReorder.tpl==
<code-php>
$TLS_no_tc_to_reorder = "Нет тестов для переупорядочивания.";
$TLS_title_change_tc_order = "Изменить порядок тестов в этой группе тестов.";
</code-php>

==gui/templates/tcTree.tpl==
<code-php>
$TLS_button_refresh = "Обновить";
$TLS_button_update_tree = "Обновить дерево";
$TLS_do_auto_update = "Обновлять дерево после каждой операции";
$TLS_no_tc_spec_av = "Нет тест-спецификаций.";
</code-php>

==gui/templates/tc_exec_assignment.tpl==
<code-php>
$TLS_btn_do = "Пуск";
$TLS_btn_update_selected_tc = "Изменить выбранные тесты";
$TLS_title_tc_exec_assignment = "Назначить прогоны тестов для плана тестирования ";
$TLS_user = "Пользователь";
$TLS_user_bulk_assignment = "Массовое назначение ответственных пользователей";
</code-php>

==gui/templates/testSetNavigator.tpl==

==gui/templates/userInfo.tpl==
<code-php>
$TLS_btn_change_passwd = "Сменить пароль";
$TLS_btn_upd_user_data = "Изменить";
$TLS_th_new_passwd = "Новый пароль";
$TLS_th_new_passwd_again = "Повторите новый пароль";
$TLS_th_old_passwd = "Старый пароль";
$TLS_title_account_settings = "Настройки профиля";
$TLS_title_change_your_passwd = "Сменить ваш пароль";
$TLS_warning_different_pwd = "Пожалуйста, повторите еще раз ваш новый пароль. Введенные пароли не совпадают.";
$TLS_warning_empty_pwd = "Пароль должен быть не пуст!";
$TLS_your_password_is_external = "Ваш пароль ведётся во внешней системе";
</code-php>

==gui/templates/usersassign.tpl==
<code-php>
$TLS_TestProject = "проект";
$TLS_User = "Пользователь";
$TLS_btn_change = "Изменить";
$TLS_caption_assign_testplan_user_roles = "Назначить роли плана тестирования пользователям";
$TLS_caption_assign_testproject_user_roles = "Назначить роли проекта пользователям";
$TLS_menu_assign_testproject_roles = "Назначить роли проекта";
$TLS_th_roles = "Роли";
$TLS_title_assign_roles = "Назначить роли";
</code-php>

==gui/templates/usersedit.tpl==
<code-php>
$TLS_button_reset_password = "Сбросить пароль";
$TLS_caption_user_details = "Свойства пользователя";
$TLS_th_password = "Пароль";
$TLS_warning_empty_first_name = "Пожалуста, введите имя";
$TLS_warning_empty_last_name = "Пожалуйста, введите фамилию";
$TLS_warning_empty_login = "Пожалуйста, введите логин";
</code-php>

==gui/templates/attachmentupload.tpl==
<code-php>
$TLS_attachment_upload_ok="Файл загружен.";
$TLS_enter_attachment_title = "Введите заголовок для этого вложения.";
$TLS_import_was_ok = "Импорт прошел успешно.";
$TLS_max_size_cvs_file = "Максимальный размер файла:";
$TLS_title_upload_attachment = "Загрузить вложение";
</code-php>

==gui/templates/rolesview.tpl==
<code-php>
$TLS_N_A = "N/A";
$TLS_alt_delete_role = "Удалить роль";
$TLS_alt_edit_role = "Править роль";
$TLS_btn_confirm_delete = "Удалить";
$TLS_no_roles = "Нет ролей";
$TLS_title_roles = "Доступные роли";
$TLS_warning_users_will_be_reset = "'Задетым пользователям' будет назначена гостевая роль!";
</code-php>

==gui/templates/tcexport.tpl==
<code-php>
$TLS_export_with_keywords = "Экспортировать с ключевыми словами";
</code-php>

==gui/templates/buildView.tpl==
<code-php>
$TLS_alt_active_build = "Активная сборка";
$TLS_alt_edit_build = "Редактировать эту сборку";
$TLS_alt_open_build = "Открыть сборку";
$TLS_btn_build_create = "Создать";
$TLS_no_builds = "В этот плане тестирования сборок не определено.";
$TLS_th_description = "Описание";
$TLS_th_open = "Открыть";
$TLS_title_build_list = "Список существующих сборок";
$TLS_warning_delete_build = <<<END
<p>Вы действительно хотите уничтожить эту сборку? <p>
Все связанные данные (в частности, результаты тестов) будут также удалены!";
END;
</code-php>

==gui/templates/planView.tpl==
<code-php>
$TLS_testplan_alt_delete_tp = "Удалить этот план тестирования?";
$TLS_testplan_alt_edit_tp = "Править план тестирования";
$TLS_testplan_msg_delete_confirm = <<<END
Вы уверены, что хотите удалить план тестирования? <p>
План тестирования можно деактивировать не удаляя.
END;

$TLS_testplan_th_delete = "Удалить";
$TLS_testplan_title_list = "Список планов тестирования";
$TLS_testplan_txt_empty_list = <<<END
Ни одного плана тестирования не определено! <p>
Чтобы воспользоваться функциональностью прогонов тестов, нужно
создать хотя бы один.
END;
$TLS_alt_active_testplan = "Активный план тестирования";
</code-php>

==gui/templates/mainPage_left.tpl==
<code-php>
$TLS_href_assign_user_roles = "Назначить пользовательские роли";
$TLS_href_browse_tc = "Просмотр тестов";
$TLS_href_cfields_management = "Управление пользовательскими полями";
$TLS_href_cfields_tproject_assign = "Привязка пользовательских полей";
$TLS_href_create_product = "Создать новый проект";
$TLS_href_edit_product = "Править/Удалить проект";
$TLS_href_edit_tc = "Редактировать тесты";
$TLS_href_keywords_assign = "Привязать ключевые слова";
$TLS_href_keywords_manage = "Управление ключевыми словами";
$TLS_href_keywords_view = "Просмотр ключевых слов";
$TLS_href_print_tc = "Печать тестов";
$TLS_href_req_assign = "Привязать требования";
$TLS_href_req_spec = "Спецификация требований";
$TLS_href_roles_management = "Управление ролями";
$TLS_href_search_tc = "Искать тест(ы)";
$TLS_href_user_management = "Управление пользователями";
$TLS_title_requirements = "Требования";
$TLS_title_test_spec = "Спецификации тестов";
$TLS_title_product_mgmt = "Управление проектами";
</code-php>

==gui/templates/mainPage_right.tpl==
<code-php>
$TLS_filter_tp_by_product = "Фильтровать план тестирования по проектам";
$TLS_href_add_test_case = "Добавить тест(ы)";
$TLS_href_build_new = "Управление сборками";
$TLS_href_execute_test = "Выполнить тесты";
$TLS_href_plan_assign_priority = "Установить приоритеты";
$TLS_href_plan_define_priority = "Определить правила приоритетов";
$TLS_href_plan_management = "Управление планами тестирования";
$TLS_href_plan_mstones = "Управление вехами";
$TLS_href_print_tc_suite = "Печать плана тестирования";
$TLS_href_remove_test_case = "Удалить тест(ы)";
$TLS_href_rep_and_metrics = "Отчеты и метрики";
$TLS_href_tc_exec_assignment = "Поручить прогон тестов";
$TLS_href_upd_mod_tc = "Сохранить измененные тесты";
$TLS_msg_no_rights_for_tp = "- недоступен (У вас нет доступа ни для одного плана тестирования)";
$TLS_testplan_role = "Роль плана тестирования";
$TLS_title_test_case_suite = "Содержание плана тестирования";
$TLS_title_test_execution = "Выполнение плана тестирования";
$TLS_title_test_plan_mgmt = "Управление планами тестирования";
$TLS_href_newest_tcversions = "Показать тесты с самыми свежими версиями";
</code-php>

==lib/execute/bug_add.php==
<code-php>
$TLS_bug_added = "Баг добавлен";
$TLS_error_bug_does_not_exist_on_bts="Бага с таким ID не зарегистрировано в BTS!";
$TLS_error_wrong_BugID_format = "Неверный формат BugID!";
</code-php>

==lib/execute/bug_delete.php==
<code-php>
$TLS_bugdeleting_was_ok = "Баг успешно удален.";
</code-php>

==lib/functions/doAuthorize.php==
<code-php>
$TLS_error_ldap_auth_failed = "LDAP-аутентификация не удалась";
$TLS_error_ldap_bind_failed = "Не удалось выполнить LDAP-binding";
$TLS_error_ldap_server_connect_failed = "Не удалось соединится с LDAP-сервером";
$TLS_error_ldap_update_failed = "Обновление LDAP не удалось";
$TLS_error_ldap_user_not_found = "LDAP-пользователь не найден";
</code-php>

==lib/functions/product.inc.php==
<code-php>
$TLS_info_product_delete_fails = "При удалении этого проекта произошла ошибка";
</code-php>

==lib/functions/results.inc.php==
<code-php>
$TLS_trep_failing = "Провалены";
$TLS_trep_passing = "Прошли";
$TLS_trep_status_for_build = "Состояние для сборки";
$TLS_trep_status_for_ts = "Состояние для группы тестов";
$TLS_unassigned = "Не назначены";
</code-php>

==lib/functions/resultsMoreBuilds.inc.php==
<code-php>
$TLS_bugs = "Связанные Баги";
$TLS_builds_selected = "Сборка(и)";
$TLS_case_not_run_warning = "Тест не запущен";
$TLS_category_header = "Группа тестов =";
$TLS_daterun = "Дата запуска";
$TLS_last_status = "Последнее состояние";
$TLS_number_blocked = "# блокированных";
$TLS_number_cases = "# тестов";
$TLS_number_executions = "# тест-пусков";
$TLS_number_failed = "# тест-сбоев";
$TLS_number_not_run = "# не запущено";
$TLS_number_passed = "# пройденных";
$TLS_owner = "Тестировщик";
$TLS_owner_header = "Tester =";
$TLS_runby = "Запущен тестировщиком ";
$TLS_test_plan_name = "План тестирования";
</code-php>

==lib/functions/roles.inc.php==
<code-php>
$TLS_desc_cfield_management = "Управление пользовательскими полями";
$TLS_desc_cfield_view = "Просмотр пользовательских полей (read-only)";
$TLS_desc_mgt_modify_key = "Управление ключевыми словами";
$TLS_desc_mgt_modify_product= "Управление проектами";
$TLS_desc_mgt_modify_req = "Управление требованиями";
$TLS_desc_mgt_modify_tc = "Создание/правка тестов";
$TLS_desc_mgt_modify_users = "Управление пользователями";
$TLS_desc_mgt_view_key = "Просмотр ключевых слов (read-only)";
$TLS_desc_mgt_view_req = "Просмотр требований (read-only)";
$TLS_desc_mgt_view_tc = "Просмотр тестов (read-only)";
$TLS_desc_role_management = "Управление ролями";
$TLS_desc_testplan_create_build = "Создание/редактирование сборки";
$TLS_desc_testplan_execute = "Выполнение плана тестирования";
$TLS_desc_testplan_metrics = "Метрики плана тестирования";
$TLS_desc_testplan_planning = "Составление плана тестирования";
$TLS_desc_user_role_assignment = "Назначение ролей";
$TLS_error_duplicate_rolename = "Роль с таким именем уже есть!";
$TLS_error_role_no_rights = "Вы не можете создать роль без каких-либо прав!";
$TLS_error_role_no_rolename = "Вам нужно ввести имя для этой роли.";
$TLS_mgt_testplan_create = "Создать/править план тестирования";
</code-php>

==lib/functions/testproject.class.php==
<code-php>
$TLS_error_creating_req_spec = "Ошибка при создании спецификации требования";
$TLS_info_product_name_empty = "Нельзя давать пустое имя.";
$TLS_keyword_already_exists = "Такое ключевое слово уже есть";
$TLS_string_contains_bad_chars = "Введенная строка содержит недопустимые символы.";
$TLS_warning_duplicate_req_title= "Требование с таким заголовком уже есть.";
</code-php>

==lib/functions/requirements.inc.php==
<code-php>
$TLS_conflict = "Конфликт";
$TLS_error_deleting_req = "Ошибка при удалении требования(й).";
$TLS_error_inserting_req = "Ошибка при вставке требования(й).";
$TLS_error_updating_req = "Ошибка при правке требования(й).";
$TLS_error_updating_reqspec = "Ошибка при правке спецификаций требований.";
$TLS_file_is_not_xml = "Файл не распознан как корректный XML, и не может быть использован.";
$TLS_ok = "OK";
$TLS_req_import_format_description1 = " - тип CSV требует три поля на каждую запись: 'req_doc_id','title','description'";
$TLS_req_import_format_description2 = " - CSV, экспортированный из DOORS требует запись-заголовок.";
$TLS_req_import_result_overwritten = "перезаписано!";
$TLS_req_import_result_skipped = "пропущено";
$TLS_req_state_not_testable = "не тестируемо";
$TLS_req_state_valid = "актуально";
$TLS_the_format_req_xml_import = "Неверный XML-формат для импорта требований";
$TLS_warning_duplicate_reqdoc_id = "Не уникальный (дублирующий) id документа";
</code-php>

==lib/functions/testsuite.class.php==
<code-php>
$TLS_component_name_already_exists = "Группа тестов с таким именем уже зарегистрирована";
$TLS_testsuite = "Группа тестов";
</code-php>

==lib/functions/exec.inc.php==
<code-php>
$TLS_test_results_submitted = "Результаты тестов отправлены.";
</code-php>

==lib/functions/print.inc.php==
<code-php>
$TLS_author = "Автор";
$TLS_printed_by_TestLink_on = "Распечатано TestLink'ом ";
$TLS_title_toc = "Содержание";
$TLS_passfail = "Пройден / Провален";
$TLS_testnotes = "Заметки к тесту";
</code-php>

==lib/functions/testcase.class.php==
<code-php>
$TLS_testcase_name_already_exists = "Тест с таким именем уже есть!";
$TLS_the_format_tc_xml_import = "";
</code-php>

==lib/functions/info.inc.php==
<code-php>
$TLS_email_sent_message = "Ваше письмо отослано.";
</code-php>

==lib/functions/users.inc.php==
<code-php>
$TLS_Unknown = "Неизвестно";
$TLS_duplicate_login = "Пользователь с таким логином уже есть!";
$TLS_login_must_not_be_empty = "Логин не должен быть пустым!";
$TLS_wrong_old_password = "Старый пароль неверен!";
</code-php>

==lib/functions/email_api.php==
<code-php>
$TLS_stmp_host_unconfigured = "Некорректно указан SMTP host!";
</code-php>

==lib/functions/common.php==

==lib/functions/configCheck.php==
<code-php>
$TLS_attachments_dir = "каталог для вложений:";
$TLS_bts_connection_problems = <<<END
Не удалось соединиться с вашей Bug Tracking System.<p>
Пожалуйста, проверьте настройки.<p>
Будьте внимательны, эта проблема
снижает производительность TestLink'а.
END;

$TLS_but_directory_is_not_writable = "Каталог закрыт для записи!";
$TLS_directory_is_writable = "Каталог открыт для записи.";
$TLS_does_not_exist = "не существует";
$TLS_exists = "существует";
$TLS_ldap_extension_not_loaded=<<<END
Метод аутентификации указан как LDAP </br>
однако PHP/LDAP extension не загружено =>
Вам не удастся войти в систему.
Пожалуйста, свяжитесь с администратором TestLink'а.
END;
$TLS_sec_note_admin_default_pwd = "Вам необходимо сменить пароль по умолчанию у пользователя 'admin'!";
$TLS_sec_note_remove_install_dir = "Инсталляционный каталог должен быть удален!";
</code-php>

==lib/general/frmWorkArea.php==
<code-php>
$TLS_create_a_build = "Создать новую сборку";
$TLS_no_build_warning_part1 = "Ни одной сборки для этого тест плана не создано.";
$TLS_no_build_warning_part2 = "Создайте их или попросите об этом свое руководство.";
</code-php>

==lib/general/myTPInfo.php==
<code-php>
$TLS_no_testplans_available = "К сожалению, ни одного плана тестирования не доступно";
</code-php>

==lib/general/tlsmarty.inc.php==

==lib/keywords/keywords.inc.php==
<code-php>
$TLS_empty_keyword_no = "Ключевое слово должно быть непустым!";
$TLS_keywords_char_not_allowed = "Запятые и кавычки недопустимы в ключевых словах!";
$TLS_tc_kw_update_fails1 = "Тест";
$TLS_tc_kw_update_fails2 = " дал сбой ";
$TLS_the_format_keyword_csv_import = "keyword;notes";
$TLS_the_format_keyword_xml_import = "<keywords><keyword name=\"name\">Notes</keyword></keywords>";
</code-php>

==lib/keywords/keywordsView.php==
<code-php>
$TLS_kw_delete_fails = "Не удалось удаление ключевого слова!";
$TLS_kw_update_fails = "Не удалась правка ключевого слова!";
</code-php>

==lib/keywords/keywordsAssign.php==
<code-php>
$TLS_assigned_kword = "Связанные ключевые слова";
$TLS_available_kword = "Доступные ключевые слова";
</code-php>

==lib/plan/buildNew.php==
<code-php>
$TLS_cannot_add_build = "Невозможно добавить сборку!";
$TLS_cannot_delete_build = "Невозможно удалить сборку!";
$TLS_cannot_update_build = "Ошибка при правке сборки!";
$TLS_warning_duplicate_build = "Сборка с таким идентификатором уже есть.";
</code-php>

==lib/plan/plan.inc.php==
<code-php>
$TLS_warning_empty_milestone_name = "Обязательно введите имя для вехи!";
$TLS_warning_enter_valid_date = "Введенная дата некорректна!";
$TLS_warning_invalid_percentage_value = "Значения-проценты должны быть от 0 to 100 (%)";
$TLS_warning_milestone_date = "Веха не может иметь дату раньше чем 'сегодня'!";
$TLS_warning_percentage_value_higher_than_100 = "Сумма всех значений-процентов не должна быть больше 100!";
</code-php>

==lib/plan/planMilestones.php==
<code-php>
$TLS_milestone_delete_fails = "Не удалось удалить веху!";
$TLS_warning_milestone_add_failed = "Не удалось добавить веху!";
$TLS_warning_milestone_update_failed = "Не удалось править веху!";
</code-php>

==lib/plan/planOwner.php==
<code-php>
$TLS_opt_imp_high = "Высокая";
$TLS_opt_imp_low = "Низкая";
$TLS_opt_imp_medium = "Средняя";
</code-php>

==lib/plan/planTestersEdit.php==
<code-php>
$TLS_title_assign_tp = "Поручить планы тестирования пользователю: ";
$TLS_title_assign_users = "Назначить пользователей на план тестирования: ";
</code-php>

==lib/plan/planTestersNavigator.php==
<code-php>
$TLS_nav_test_plan = "Навигатор - Планы тестирования";
$TLS_nav_users = "Навигатор - Пользователи";
</code-php>

==lib/plan/planUpdateTC.php==
<code-php>
$TLS_category_has_changed = "Группа тестов изменена";
$TLS_component_has_changed = "Группа тестов изменена";
$TLS_deleted = "удалена";
$TLS_different_versions = "Различные версии";
$TLS_plan_update_no_tc_updated = "Ни один тест не изменен";
$TLS_planupdate_tc_deleted1 = "Тест";
$TLS_planupdate_tc_deleted2 = "был удален.";
$TLS_planupdate_tc_updated1 = "Тест";
$TLS_planupdate_tc_updated2 = "был изменен.";
$TLS_tcorder_has_changed = "Порядок тестов был изменен";
$TLS_updated = "изменен";
</code-php>

==lib/plan/testSetNavigator.php==
<code-php>
$TLS_title_test_plan_navigator = "Навигация по планам тестирования";
</code-php>

==lib/plan/testSetRemove.php==
<code-php>
$TLS_tcase_removed_from_tplan="тест удален из плана тестирования";
$TLS_multiple_tcase_removed_from_tplan="Тесты удалены из плана тестирования";
</code-php>

==lib/plan/planEdit.php==
<code-php>
$TLS_testplan_created_ok = "План тестирования был создан";
$TLS_update_tp_failed1 = "Правка плана тестирования '";
$TLS_update_tp_failed2 = "' не удалась";
$TLS_warning_duplicate_tplan_name = "План тестирования с таким именем уже есть. Выберите другое имя!";
</code-php>

==lib/print/selectData.php==
<code-php>
$TLS_opt_show_doc_header = "Показать заголовок документа";
$TLS_opt_show_tc_body = "Показать тело теста";
$TLS_opt_show_tc_summary = "Показать резюме теста";
$TLS_opt_show_toc = "Показать Содержание";
$TLS_opt_show_tc_author = "Показать автора теста";
$TLS_opt_show_passfail = "Показать статус «пройден/провален» и заметки";
$TLS_title_tc_print_navigator = "Навигация - Печать спецификации тестов";
$TLS_title_tp_print_navigator = "Навигация - Печать плана тестирования";
</code-php>

==lib/project/projectedit.php==
<code-php>
$TLS_error_product_name_duplicate = "Уже есть проект с именем %s. <br>Пожалуйста, выберите другое имя";
$TLS_info_no_more_prods = "проектов больше нет.";
$TLS_info_product_activated = "проект активирован.";
$TLS_info_product_inactivated = "проект деактивирован.";
$TLS_info_product_not_deleted_check_log = "Не удалось удалить проект. Проверьте лог TestLink'а.";
$TLS_info_product_was_deleted = "проект успешно удален.";
$TLS_refer_to_log = " Пожалуйста, изучите лог TestLink'а для дополнительной информации.";
$TLS_test_project_activated = "проект %s успешно активирован";
$TLS_test_project_created = "проект %s успешно создан";
$TLS_test_project_deleted = "проект %s успешно удален";
$TLS_test_project_inactivated = "проект %s успешно деактивирован";
$TLS_test_project_updated = "проект %s успешно отредактирован";
$TLS_test_project_update_failed = "Правка проекта %s не удалась!";
</code-php>

==lib/results/charts.php==
<code-php>
$TLS_maani_copyright = "flash technology предоставлена http://www.maani.us";
$TLS_graphical_reports = "Графические отчеты";
$TLS_overall_metrics = "Общие метрики";
$TLS_results_by_keyword = "Результаты по ключевому слову";
$TLS_results_by_tester = "Рузультаты по тестировщику";
$TLS_results_top_level_suites = "Результаты по топ группам тестов";
</code-php>

==lib/req/reqImport.php==
<code-php>
$TLS_file_is_not_ok_for_import_type = "Кажется тип файла не совпадает с выбранным для импорта типом";
$TLS_file_is_not_text = "Это не текстовый файл. Использовать нельзя.";
$TLS_please_choose_req_file = "Пожалуйста, выберите файл для загрузки";
$TLS_req_import_finished = "Импорт завершен!";
</code-php>

==lib/req/reqSpecView.php==
<code-php>
$TLS_cant_create_tc_from_req_nothing_sel = "Пожалуйста, выберите требование!";
$TLS_req_created = "Требование %s успешно создано.";
</code-php>

==lib/req/reqTcAssign.php==
<code-php>
$TLS_req_msg_noselect = "Ничего не выбрано";
$TLS_req_msg_notupdated_coverage = "Покрытие не обновлено для Требований: ";
</code-php>

==lib/results/resultsBugs.php==
<code-php>
$TLS_title_test_report_all_builds = "Отчет: Результаты тестов для всех сборок";
</code-php>

==lib/results/resultsAllBuilds.php==
<code-php>
$TLS_title_metrics_x_build = " - Результаты тестов. Метрики X Сборки";
</code-php>

==lib/results/resultsByStatus.php==
<code-php>
$TLS_list_of_blocked = "Список блокированных тестов";
$TLS_list_of_failed = "Список проваленных тестов";
$TLS_list_of_not_run = "Список незапущенных тестов";
</code-php>

==lib/results/resultsTC.php==

==lib/results/resultsNavigator.php==
<code-php>
$TLS_link_charts="Диаграммы";
$TLS_link_report_blocked_tcs = "Блокированные тесты";
$TLS_link_report_failed = "Проваленные тесты";
$TLS_link_report_general_tp_metrics = "Общие метрики плана тестирования";
$TLS_link_report_metrics_active_build = "Метрики активной сборки";
$TLS_link_report_metrics_more_builds = "Запрос метрик";
$TLS_link_report_not_run="Не запущенные тесты";
$TLS_link_report_overall_build = "Общий статус всех сборок";
$TLS_link_report_reqs_coverage = "Отчет о выполнении требований";
$TLS_link_report_test = "Отчет о прогоне тестов";
$TLS_link_report_total_bugs = "Отчет об обнаруженных багах";
</code-php>

==lib/results/resultsSend.php==
<code-php>
$TLS_send_to_empty_email_warning = "Пожалуйста, введите правильный email.";
$TLS_warning_create_build_first = "Сначала Вы должны создать или импортировать сборки.";
</code-php>

==lib/results/displayMgr.php==
<code-php>
$TLS_error_sendreport_no_email_credentials = "Email для этого пользователя не указан, пожалуйста, укажите его в настройках своего профиля";
</code-php>

==lib/testcases/archive.inc.php==

==lib/testcases/listTestCases.php==

==lib/testcases/tcImport.php==
<code-php>
$TLS_please_choose_file_to_import = "Пожалуйста, выберите файл для импорта";
$TLS_title_tc_import_to = "Импорт тестов";
$TLS_title_tsuite_import_to = "Импорт группы тестов";
$TLS_wrong_xml_tcase_file = "Некорректный XML в файле с тестами";
$TLS_wrong_xml_tsuite_file = "Некорректный XML в файле с группой тестов";
</code-php>

==lib/testcases/tcexport.php==
<code-php>
$TLS_no_testcases_to_export = "Нет тестов для экспорта";
$TLS_no_testsuites_to_export = "Нет группы тестов для экспорта";
$TLS_title_tc_export = "Экспорт теста";
$TLS_title_tc_export_all = "Экспортировать все тесты";
$TLS_title_tsuite_export = "Экспортировать все группы тестов";
$TLS_title_tsuite_export_all = "Экспортировать все группы тестов";
</code-php>

==lib/testcases/containerEdit.php==
<code-php>
$TLS_delete = "Удалить";
$TLS_delete_notice = "Внимание: Все связанные результаты прогонов будут удалены";
$TLS_warning_empty_com_name = "Пожалуйста, задайте имя для группы тестов";
</code-php>

==lib/testcases/tcEdit.php==
<code-php>
$TLS_current = "текущий";
$TLS_delete_linked = "Ссылки на планы тестирования будут удалены.";
$TLS_delete_linked_and_exec = "Ссылки на планы тестирования и результаты выполнения будут удалены.";
$TLS_error_tc_add = "При добавлении теста произошла ошибка";
$TLS_title_del_tc = "Удалить тест ";
</code-php>

==lib/usermanagement/rolesview.php==
<code-php>
$TLS_error_role_deletion = "Не удалось удалить роль!";
</code-php>

==lib/usermanagement/usersassign.php==
<code-php>
$TLS_no_test_projects = "Не заведено ни одного проекта";
$TLS_no_test_plans = "Для этого проекта не заведено ни одного плана тестирования";
$TLS_test_project_user_roles_updated = "Пользовательские роли обновлены";
$TLS_test_plan_user_roles_updated = "Пользовательские роли обновлены";
</code-php>

==lib/usermanagement/usersedit.php==
<code-php>
$TLS_user_created="Пользователь %s был успешно создан";
$TLS_user_deleted="Пользователь %s был успешно удален";
$TLS_user_not_added = "Не удалось добавить пользователя!";
</code-php>

==lib/usermanagement/rolesedit.php==
<code-php>
$TLS_error_role_creation = "Не удалось создать роль!";
$TLS_error_role_update = "Не удалось исправить роль!";
</code-php>

==lib/cfields/cfields_edit.php==
<code-php>
$TLS_cf_name_exists = "Пользовательское поле с таким именем уже существует. Пожалуста, выберите другое имя.";
$TLS_error_creating_cf = "Не удалось создать пользовательское поле!";
$TLS_do_update = "исправлено";
$TLS_do_delete = "удалено";
$TLS_do_add = "добавлено";
</code-php>

==resultsBugs.tpl==
<code-php>
$TLS_Open="Открыто";
$TLS_Resolved="Исправленных";
$TLS_Total="Всего";
$TLS_TCs_with_Bugs="Тестов с багами";
</code-php>

Strings.txt (TestLink-RU)

2007-10-07T13:19:14Z

Andrew: /* lib/results/resultsNavigator.php */

[[Category:TestLink]]

Статьяz с основной локализацией интерфейса. Статья разбита по разделам, в соответствии с разделами в оригинальном файле <tt>strings.txt</tt>. По ссылке «[[#Скачать|скачать]]» можно получить готовый PHP-файл, который нужно разместить в каталоге
testlink\locale\ru_RU\strings.txt

=Скачать=
[{{SERVER}}{{localurl:Special:CisGetPHPPage|pagetitle={{PAGENAMEE}}}} Получить PHP-код]

= Оригинал (наиболее полный английский перевод) =
* http://testlink.cvs.sourceforge.net/testlink/testlink/locale/en_GB/

=Разделы файла strings.txt (ru_RU)=
<code-php>
/**
* TestLink Open Source Project - http://testlink.sourceforge.net/
*
* Filename $RCSfile: strings.txt,v $
*
* @version $Revision$
* @modified $Date$ $Author$
*
* @author Vadim Ivanchenko, Stas Fomin, and russian Testlink community.
* http://lib.custis.ru/index.php/TestLink:_strings.txt_%28RU%29
*
*
**/

$TLS_STRINGFILE_CHARSET = "UTF-8";
</code-php>

==General==
<code-php>
$TLS_asc = "по возрастанию";
$TLS_btn_no = "Нет";
$TLS_create = "Создать";
$TLS_desc = "по убыванию";
$TLS_test_case = "Тест";
$TLS_testcase = $TLS_test_case;
$TLS_test_plan = "План тестирования";
$TLS_testplan = $TLS_test_plan;
$TLS_test_suite = "Группа тестов";
$TLS_SRS = "SRS";
$TLS_Role = "Роль";
$TLS_Keyword = "Ключевое слово";
$TLS_Milestone = "Веха";
$TLS_testsuite_created = "Группа тестов создана";
$TLS_requirement = "Требование";
$TLS_assigned = "назначен";
$TLS_unassigned = "свободен";
$TLS_import_file_type = "Тип импортируемого файла";
$TLS_max_file_size_is = "Макс. размер файла";
$TLS_supported_file_formats = "Поддерживаемые форматы файлов";
</code-php>

==firstLogin.php==
<code-php>
$TLS_cant_create_user = "К сожалению, не удалось создать ваш логин. Пожалуйста, свяжитесь с администратором!";
$TLS_empty_email_address = " Пожалуйста, укажите e-mail!";
$TLS_empty_first_name = " Пожалуйста, укажите имя пользователя.";
$TLS_empty_last_name = " Пожалуйста, укажите фамилию.";
$TLS_fatal_page_title = "TestLink ::: Fatal Error";
$TLS_invalid_user_name = "Некорректный логин пользователя. Пожалуйста, придумайте другой.";
$TLS_passwd_dont_match = "Два введенных пароля не совпадают. Учтите, что пароли чувствительны к регистру, и попробуйте ещё раз.";
$TLS_user_cant_be_created_because = "Не удалось создать ваш аккаунт. Причина:";
$TLS_user_name_exists = "Этот логин пользователя уже используется. Пожалуйста, выберите другой.";
$TLS_valid_user_name_format = "Логин пользователя может состоять только из алфавитно-цифровых символов, пробелов, дефисов и подчеркиваний.";
$TLS_warning_empty_pwd = "Пожалуйста, укажите пароль. Пароль не может быть пустым.";
$TLS_your_info_please = "Введите информацию о пользователе";
</code-php>

==index.php==
<code-php>
$TLS_main_page_title = "TestLink::Главная страница";
</code-php>

==keywordsimport.php==
<code-php>
$TLS_please_choose_keywords_file = "Пожалуйста, выберите файл для загрузки";
$TLS_keywords_file = "Файл с ключевыми словами";
</code-php>

==lostPassword.php==
<code-php>
$TLS_bad_user = "Пользователь не найден, попробуйте еще";
$TLS_contact_admin = "<br> Если проблемы будут продолжаться, пожалуйста, свяжитесь с администратором системы.";
$TLS_mail_empty_address = "Вы не указали email-адреса в вашем профиле! Теперь, чтобы сбросить пароль вам нужно связаться с администратором TestLink-системы.";
$TLS_mail_passwd_subject = "Ваш новый пароль к TestLink'у.";
$TLS_mail_problems = "Ошибка в почтовых настройках, пожалуйста, свяжитесь с администратором.";
$TLS_page_title_lost_passwd = "TestLink - Утерян пароль";
$TLS_your_info_for_passwd = "Заполните информацию о вашем пользователе, и пароль будет вам выслан по почте.";
$TLS_your_password_is = "Ваш пароль к TestLink'у: <br>";
</code-php>

==login.php==
<code-php>
$TLS_bad_user_passwd = "Логин или пароль неверен. Попробуйте ещё!";
$TLS_login_msg_session_exists1 = "Ваша сессия в этом броузере ещё активна. Пожалуйста, используйте ";
$TLS_login_msg_session_exists2 = " если вы хотите обновить вашу сессию.";
$TLS_logout_link = "Выход";
$TLS_passwd_lost = "Ваш пароль выслан вам по email на адрес, который вы указали при регистрации. Проверьте вашу почту. В случае проблем, обратитесь к администратору вашего TestLink'а.";
$TLS_password_reseted="Новый пароль выслан вам по почте";
$TLS_please_login = "Пожалуйста, войдите в систему...";
$TLS_session_expired = "Время ваша сессии окончилось. Пожалуйста, войдите в систему заново.";
$TLS_your_first_login = "Добро пожаловать в TestLink! Сейчас у вас только гостевой доступ. Для большего, нужно войти в систему.";
</code-php>

==planPriority.php==
<code-php>
$TLS_high_priority = "Высокий";
$TLS_low_priority = "Низкий";
$TLS_medium_priority = "Средний";

$TLS_high_risk = "Высокий";
$TLS_low_risk = "Низкий";
$TLS_medium_risk = "Средний";

$TLS_high_importance = "Высокая";
$TLS_low_importance = "Низкая";
$TLS_medium_importance= "Средняя";
</code-php>

==tcEdit.php==
<code-php>
$TLS_tc_created = "Тест %s успешно создан";
$TLS_tc_deleted = "Тест %s успешно удален";
$TLS_tc_updated = "Тест %s отредактирован успешно";
$TLS_tc_update_failed = "Не удалась правка теста %s!";
</code-php>

==gui/templates/attachment404.tpl==
<code-php>
$TLS_btn_close = "Закрыть";
$TLS_error_attachment_not_found = "Ошибка: Вложение не найдено!";
$TLS_title_downloading_attachment = "Загружаем вложение";
</code-php>

==gui/templates/attachmentdelete.tpl==
<code-php>
$TLS_deleting_was_ok = "Вложение удалено.";
$TLS_error_attachment_delete = "При удалении вложения произошла ошибка!";
$TLS_title_delete_attachment = "Удалить вложение";
</code-php>

==gui/templates/containerDelete.tpl==
<code-php>
$TLS_btn_yes_del_comp = "Да, удалить группу тестов";
$TLS_container_title_testsuite =$TLS_test_suite;
$TLS_linked_but_not_executed="Связан с одним или более планом тестирования, но не выполнялась";
$TLS_question_del = "Действительно удалить";
$TLS_th_link_exec_status = "Статус исполнения и связей";
</code-php>

==gui/templates/containerNew.tpl==
<code-php>
$TLS_btn_create_testsuite = "Создать группу тестов";
$TLS_tc_keywords = "Ключевые слова";
$TLS_title_create = "Создать";
$TLS_warning_empty_testsuite_name = "Пожалуйста, задайте имя для группы тестов";
</code-php>

==gui/templates/bug_add.tpl==
<code-php>
$TLS_btn_add_bug = "Добавить баг";
$TLS_bug_id = "Bug id";
$TLS_button_enter_bug = "Создать новый баг";
$TLS_title_bug_add = "Добавить баг";
$TLS_link_bts_create_bug = "Доступ к системе регистрации багов";
</code-php>

==gui/templates/bug_delete.tpl==
<code-php>
$TLS_title_delete_bug = "Удалить баг";
</code-php>

==gui/templates/containerMove.tpl==
<code-php>
$TLS_btn_cp = "Копировать";
$TLS_btn_move = "Переместить";
$TLS_choose_target = "Выберите куда";
$TLS_cont_move_first = "Переместить это";
$TLS_cont_move_second = "в другое";
$TLS_copy_keywords = "Копировать ключевые слова";
$TLS_defined_exclam = "определен !";
$TLS_include_nested = "Включая вложенные данные (только для копирования).";
$TLS_sorry_further = "К сожалению, больше ничего нет ";
$TLS_title_move_cp = "Переместить/Скопировать";
</code-php>

==gui/templates/reqCreate.tpl==
<code-php>
$TLS_btn_cancel = "Отменить";
$TLS_btn_create = "Создать";
$TLS_help = "Помощь";
$TLS_req_create = "Создать требование";
$TLS_req_doc_id = "DOC-ID";
$TLS_req_spec = "Спецификация требований";
$TLS_reqs = "Требования";
$TLS_scope = "Описание";
$TLS_status = "Состояние";
$TLS_title = "Заголовок";
$TLS_warning_empty_req_title = "Заголовок требования должен быть не пуст!";
$TLS_warning_empty_reqdoc_id = "ID документа-требования не должен быть пуст!";
</code-php>

==gui/templates/containerOrder.tpl==
<code-php>
$TLS_btn_upd = "Обновить";
$TLS_no_nodes_to_reorder = "К сожалению, тут нечего упорядочивать.";
$TLS_node = "Имя";
$TLS_th_id = "ID";
$TLS_th_node_type = "Тест / Группа тестов";
$TLS_th_order = "Порядок";
$TLS_title_change_node_order = "Изменить порядок 'потомков'";
$TLS_node_type_dbtable_testsuites=$TLS_test_suite;
$TLS_node_type_dbtable_testcases=$TLS_testcase;
</code-php>

==gui/templates/containerView.tpl==
<code-php>
$TLS_alt_del_com = "Удалить эту группу тестов";
$TLS_alt_edit_com = "Править дату и заголовок для этой группы тестов";
$TLS_alt_move_cp_com = "Переместить или скопировать эту группу тестов в другой проект";
$TLS_btn_del_com = "Удалить";
$TLS_btn_edit_com = "Править";
$TLS_btn_export_all_testsuites = "Экспортировать все группы тестов";
$TLS_btn_export_tc = "Экспортировать тест(ы)";
$TLS_btn_export_testsuite = "Экспортировать группу тестов";
$TLS_btn_import_tc = "Импортировать тест(ы)";
$TLS_btn_import_testsuite = "Импортировать группу тестов";
$TLS_btn_move_cp_com = "Переместить/Копировать";
$TLS_btn_new_cat = "Новая группа тестов";
$TLS_btn_new_com = "Новая группа тестов";
$TLS_btn_new_tc = "Создать тест(ы)";
$TLS_btn_reorder_cat = "Переупорядочить потомков";
$TLS_edit_testproject_basic_data = "Править основные данные проекта";
$TLS_th_notes = "Описание";
$TLS_th_product_name = "Имя проекта";
</code-php>

==gui/templates/cfields_edit.tpl==
<code-php>
$TLS_available_on = "Доступно для";
$TLS_btn_add = "Добавить";
$TLS_btn_delete = "Удалить";
$TLS_btn_ok = "Ok";
$TLS_custom_field = "Пользовательское поле";
$TLS_enable_on_design = "Разрешить при <br>спецификации теста";
$TLS_enable_on_exec = "Разрешить при <br>прогоне теста";
$TLS_label = "Метка";
$TLS_name = "Имя";
$TLS_popup_delete_custom_field = "Вы уверены, что хотите удалить пользовательское поле?";
$TLS_possible_values = "Возможные значения";
$TLS_show_on_design = "Показывать при <br>спецификации теста";
$TLS_show_on_exec = "Показывать при <br>прогоне теста";
$TLS_testcase = $TLS_test_case;
$TLS_title_cfields_mgmt = "Пользовательские поля";
$TLS_type = "Тип";
$TLS_warning_empty_cfield_label = "Пожалуйста, введите метку для этого пользовательского поля.";
$TLS_warning_empty_cfield_name = "Пожалуйста, введите имя этого пользовательского поля.";
</code-php>

==gui/templates/inc_update.tpl==
<code-php>
$TLS_info_failed_db_upd = "Не удалось обновить базу данных!";
$TLS_info_failed_db_upd_details = "Не удалось обновить базу данных! - Подробности:";
$TLS_invalid_query = "Ошибка:";
$TLS_warning = "Предупреждение!!";
$TLS_was_success = " был(и) успешно ";
</code-php>

==gui/templates/execNavigator.tpl==
<code-php>
$TLS_TestPlan = "План тестирования";
$TLS_btn_apply_filter = "Применить фильтр";
$TLS_btn_update_menu = "Обновить меню";
$TLS_caption_nav_filter_settings = "Параметры выборки";
$TLS_current_build = "Текущая сборка";
$TLS_filter_owner = "Ответственный";
$TLS_filter_result = "Результат";
$TLS_filter_tcID = "Фильтр: ID теста";
$TLS_keyword = "Ключевое слово";
$TLS_test_status_all_status="Все";
</code-php>

==gui/templates/mainPage.tpl==
<code-php>
$TLS_th_my_perc_completed = "У меня выполнено [%]";
$TLS_th_name = "Имя";
$TLS_th_perc_completed = "Выполнено [%]";
$TLS_title_your_tp_metrics = "Ваши метрики для плана тестирования";
</code-php>

==gui/templates/newest_tcversions.tpl==
<code-php>
$TLS_linked_version = "Связанная версия";
$TLS_newest_version = "Самая новая из доступных активных версий";
$TLS_title_newest_tcversions = "Самые новые версии связанных тестов";
</code-php>

==gui/templates/emailSent.tpl==
<code-php>
$TLS_send_test_report = "- Послать тест-отчёт";
</code-php>

==gui/templates/reqImport.tpl==
<code-php>
$TLS_Result = "Результат";
$TLS_Title = "Заголовок";
$TLS_btn_back2srs = "Назад, к спецификации требований";
$TLS_btn_import = "Импорт";
$TLS_btn_upload_file = "Загрузить файл";
$TLS_check_req_file_structure = "Пожалуйста, проверьте формат файла. Не получается получить из этого файла требования";
$TLS_local_file = "Файл:";
$TLS_max_size_cvs_file1 = "Максимальный размер для этого файла";
$TLS_max_size_cvs_file2 = "kB";
$TLS_req_import_check_note = "Пожалуйста, разрешите возможные конфликты и запустите процесс импорта.";
$TLS_req_import_dont_empty = "Не импортируйте элементы с пустой Сферой";
$TLS_req_import_option_double = "Добавить ещё с тем же заголовком";
$TLS_req_import_option_header = "Разрешить конфликт";
$TLS_req_import_option_overwrite = "Обновить существующий";
$TLS_req_import_option_skip = "Пропускать импорт дублирующих требований";
$TLS_req_import_type = "Тип:";
$TLS_req_msg_norequirement = "Нет требований";
$TLS_required_cvs_format = "Формат файла с требованиями:";
$TLS_title_choose_file_type = "Выберите тип файла";
$TLS_title_choose_local_file = "Выберите файл для загрузки";
$TLS_title_req_import = "Загрузка требований";
$TLS_title_req_import_check_input = "Проверьте импортируемые данные";
</code-php>

==gui/templates/inc_attachments.tpl==
<code-php>
$TLS_alt_delete_build = "Удалить эту сборку";
$TLS_alt_delete_attachment = "Удалить это вложение";
$TLS_attached_files = "Вложенные файлы";
$TLS_attachment_feature_disabled = "вложения отключены";
$TLS_button_upload = "Загрузить";
$TLS_upload_file_new_file = "Загрузить новый файл";
$TLS_warning_delete_attachment = "Действительно удалить вложение?";
</code-php>

==gui/templates/resultsNavigator.tpl==
<code-php>
$TLS_btn_print = "Печать";
$TLS_note_email_sent_t = "Примечание: email format послан на email пользователя";
$TLS_send_results = "Послать отчеты";
$TLS_send_to = "To:";
$TLS_subject = "Subject:";
$TLS_title_active_build = "Активная сборка";
$TLS_title_report_type = "Формат отчета";
$TLS_via_email = "через eMail";
</code-php>

==gui/templates/inc_attachments_upload.tpl==

==gui/templates/cfields_view.tpl==
<code-php>
$TLS_btn_cfields_create = "Создать";
$TLS_manage_cfield = "Управлять пользовательскими полями";
</code-php>

==gui/templates/inc_cat_viewer_ro_m0.tpl==
<code-php>
$TLS_cat_scope = "Описание";
$TLS_category = "Группа тестов";
$TLS_configuration = "Конфигурация";
$TLS_data = "Данные";
$TLS_not_defined = "Не определено.";
$TLS_tools = "Инструменты";
</code-php>

==gui/templates/inc_cat_viewer_rw.tpl==
<code-php>
$TLS_cat_alt_name = "Обязательно заполнить имя группы тестов.";
$TLS_cat_config = "Конфигурация";
$TLS_cat_data = "Данные";
$TLS_cat_name = "Имя группы тестов";
$TLS_cat_tools = "Инструменты";
</code-php>

==gui/templates/reqEdit.tpl==
<code-php>
$TLS_btn_update = "Обновить";
$TLS_by = "by";
$TLS_coverage = "Покрытие";
$TLS_popup_delete_req = "Удалить это требование, Вы уверены?";
$TLS_req_edit = "Править требование";
$TLS_req_msg_notestcase = "Связанных тестов нет.";
$TLS_requirement_spec = "Спецификация требования";
$TLS_test_case_id = "ID";
$TLS_title_created = "Создано:";
$TLS_title_last_mod = "Последняя правка:";
</code-php>

==gui/templates/buildNew.tpl==
<code-php>
$TLS_active = "Активная";
$TLS_enter_build = "Заголовок";
$TLS_enter_build_notes = "Описание";
$TLS_msg_build = "Замечание: Каждая сборка относится к активному плану тестирования. Описание должно включать: список развертываемых пакетов, утверждений, состояние, и т.п.";
$TLS_open = "Открыть";
$TLS_test_plan = "План тестирования";
$TLS_title_build_2 = "Управление сборками";
$TLS_title_build_create = "Создать новую Сборку";
$TLS_title_build_update = "Править Сборку";
$TLS_warning_empty_build_name = "Пожалуйста, введите имя для этой Сборки!";
</code-php>

==gui/templates/inc_comp_viewer_ro.tpl==
<code-php>
$TLS_component = "Группа тестов";
$TLS_introduction = "Введение";
$TLS_limitations = "Ограничения";
$TLS_methodology = "Методология";
$TLS_references = "Ссылки";
</code-php>

==gui/templates/inc_comp_viewer_rw.tpl==
<code-php>
$TLS_comp_alt_name = "Обязательно введите имя группы тестов.";
$TLS_comp_intro = "Введение";
$TLS_comp_lim = "Ограничения";
$TLS_comp_method = "Методология";
$TLS_comp_name = "Имя группы тестов";
$TLS_comp_ref = "Ссылки";
$TLS_comp_scope = "Описание";
</code-php>

==gui/templates/reqSpecView.tpl==
<code-php>
$TLS_btn_analyse = "Анализировать";
$TLS_btn_check_all = "Проверить все";
$TLS_btn_delete_spec = "Удалить спецификацию";
$TLS_btn_edit_spec = "Править спецификацию";
$TLS_btn_export_reqs = "Экспортировать требования";
$TLS_btn_req_create = "Создать новое требование";
$TLS_btn_spec_list = "Список спецификаций";
$TLS_btn_uncheck_all = "Убрать все отметки";
$TLS_cant_delete_req_nothing_sel = "Пожалуйста, выберите требование!";
$TLS_popup_sure_delete = "Вы уверены удалить эту спецификацию требования?";
$TLS_req_select_create_tc = "Создать тесты";
$TLS_req_select_delete = "Удалить требования";
$TLS_req_title_list = "Список требований";
$TLS_req_total = "Всего треб.";
$TLS_req_reorder = "Переупорядочить требования?";
$TLS_warning_delete_requirements = "Вы уверены удалить выбранные требования?";
$TLS_title_change_req_order = "Переупорядочивание требований";
</code-php>

==gui/templates/inc_copyrightnotice.tpl==
<code-php>
$TLS_gnu_gpl = "GNU GPL";
$TLS_lic_home = "Домой";
$TLS_lic_product = "TestLink project";
$TLS_licensed_under = "TestLink лицензируется согласно ";
</code-php>

==gui/templates/containerEdit.tpl==
<code-php>
$TLS_btn_update_testsuite = "Обновить группу тестов";
$TLS_title_edit_level = "Править";
</code-php>

==gui/templates/reqSpecAnalyse.tpl==
<code-php>
$TLS_edit = "Править";
$TLS_none = "Пусто ";
$TLS_req = "Требования";
$TLS_req_spec_change = "Изменить спецификацию требований на ";
$TLS_req_title_analyse = "Анализировать спецификацию требований ";
$TLS_req_title_covered = "Покрытые требования";
$TLS_req_title_in_tl = "Требований, зарегистрированных в TestLink";
$TLS_req_title_nottestable = "Нетестируемые требования";
$TLS_req_title_uncovered = "Непокрытые требования";
$TLS_req_title_not_in_tl = "Требований, отсутствующих в TestLink";
$TLS_req_total_count = "Всего требований";
$TLS_testcases = "Тесты";
</code-php>

==gui/templates/reqSpecCreate.tpl==
<code-php>
$TLS_action_create_srs = "Создать спецификацию требований";
$TLS_testproject = "проект";
</code-php>

==gui/templates/inc_reqView.tpl==
<code-php>
$TLS_Author = "Автор";
$TLS_last_edit = "Последняя правка: ";
</code-php>

==gui/templates/inc_res_by_comp.tpl==
<code-php>
$TLS_title_res_by_top_level_suites = "Результаты топовых групп тестов";
$TLS_trep_blocked = "Блокировано";
$TLS_trep_comp = "Группа тестов";
$TLS_trep_comp_perc = "Выполнена [%]";
$TLS_trep_failed = "Сбой";
$TLS_trep_not_run = "Не запускали";
$TLS_trep_passed = "Выполнено";
$TLS_trep_total = "Всего";
</code-php>

==gui/templates/inc_res_by_keyw.tpl==
<code-php>
$TLS_title_res_by_kw = "Результаты по ключевому слову";
$TLS_trep_kw = "Ключевое слово";
</code-php>

==gui/templates/inc_res_by_owner.tpl==
<code-php>
$TLS_title_res_by_owner = "Результаты по тестировщику";
$TLS_trep_owner = "Тестировщик";
$TLS_title_res_by_tester = "Результаты по тестировщику";
$TLS_trep_tester = "Тестировщик";
</code-php>

==gui/templates/inc_res_by_prio.tpl==
<code-php>
$TLS_tit_end_date = "Дата окончания";
$TLS_tit_milestone = "Веха";
$TLS_title_res_by_prio = "Результаты по приоритету";
$TLS_trep_milestone_goal = "Цель вехи [%]";
$TLS_trep_prio = "Приоритет";
$TLS_trep_status = "Состояние";
</code-php>

==gui/templates/inc_res_by_ts.tpl==
<code-php>
$TLS_title_res_by_ts = "Результаты по группе тестов";
$TLS_trep_imp = "Важность";
$TLS_trep_risk = "Риск";
$TLS_trep_ts = "Группа тестов";
</code-php>

==gui/templates/reqSpecEdit.tpl==

==gui/templates/inc_show_bug_table.tpl==
<code-php>
$TLS_build = "Сборка";
$TLS_caption_bugtable = "Связанные баги";
$TLS_delete_bug="Удалить баг";
$TLS_del_bug_warning_msg = "Действительно удалить этот баг?";
</code-php>

==gui/templates/reqSpecList.tpl==
<code-php>
$TLS_btn_assign_tc = "Указать тест";
$TLS_no_docs = "Нет доступных документов.";
$TLS_req_list_docs = "Спецификации требований";
</code-php>

==gui/templates/tcEdit_New_viewer.tpl==
<code-php>
$TLS_alt_add_tc_name = "Обязательно укажите имя теста.";
$TLS_expected_results = "Ожидаемые результаты";
$TLS_steps = "Шаги";
$TLS_summary = "Резюме";
$TLS_tc_title = "Заголовок тест-кейса";
</code-php>

==gui/templates/show_exec_notes.tpl==
<code-php>
$TLS_title_execution_notes = "Замечания по выполнению";
</code-php>

==gui/templates/rolesedit.tpl==
<code-php>
$TLS_btn_create_role = "Создать";
$TLS_btn_edit_role = "Править";
$TLS_caption_define_role = "Определить роль";
$TLS_caption_possible_affected_users = "Возможно влияет на следующих пользователей";
$TLS_enter_role_notes = "Введите описание роли";
$TLS_menu_assign_product_roles = "Укажите роли проекта";
$TLS_menu_assign_testplan_roles = "Укажите роли для плана тестирования";
$TLS_menu_define_roles = "Новая роль";
$TLS_menu_mod_user = "Править пользователя";
$TLS_menu_new_user = "Новый пользователь";
$TLS_menu_edit_user = "Редактировать пользователя";
$TLS_menu_view_users = "Список пользователей";
$TLS_menu_view_roles = "Просмотр ролей";
$TLS_th_cf_rights = "Права на пользовательские поля";
$TLS_th_kw_rights = "Права на ключевые слова";
$TLS_th_mgttc_rights = "Права на управление тест-кейсами";
$TLS_th_product_rights = "Права на проект";
$TLS_th_req_rights = "Права на требование";
$TLS_th_rights = "Разрешения";
$TLS_th_rolename = "Роль";
$TLS_th_tp_rights = "Права на план тестирования";
$TLS_th_user_rights = "Права пользователей";
$TLS_title_user_mgmt = "Управление пользователями";
$TLS_warning_modify_role = "Действительно исправить роль?";
</code-php>

==gui/templates/tcSearchForm.tpl==
<code-php>
$TLS_btn_find = "Найти";
$TLS_caption_search_form = "Искать тесты";
$TLS_not_applied = "Не применимо";
$TLS_th_tcid = "ID теста";
$TLS_th_tcversion = "Версия";
$TLS_th_title = "Заголовок";
$TLS_title_search_tcs = "Поиск";
</code-php>

==gui/templates/infoWindow.tpl==

==gui/templates/tcDelete.tpl==
<code-php>
$TLS_btn_yes_iw2del = "Да, удалите тест!";
$TLS_question_del_tc = "Действительно удалить тест?";
$TLS_th_executed = "Выполнено";
$TLS_th_linked_to_tplan = "Связан с планом тестирования";
$TLS_th_version = "Версия";
</code-php>

==gui/templates/tcNew.tpl==
<code-php>
$TLS_title_new_tc = "Создать тест";
$TLS_warning_empty_tc_title = "Пожалуйста, задайте заголовок для теста";
</code-php>

==gui/templates/tcImport.tpl==
<code-php>
$TLS_title_imp_tc_data = "Импорт данных для теста";
</code-php>

==gui/templates/keywordsimport.tpl==
<code-php>
$TLS_title_keyword_import_to = "Импортировать ключевые слова в ";
$TLS_title_keyword_import = "Импорт ключевых слов";
</code-php>

==gui/templates/keywordsexport.tpl==
<code-php>
$TLS_btn_export = "Экспорт";
$TLS_title_req_import_to = "Импортировать требования в документ:";
</code-php>

==gui/templates/cfields_tproject_assign.tpl==
<code-php>
$TLS_btn_assign = "Привязать";
$TLS_btn_cfields_active_mgmt = "Обновить активное состояние";
$TLS_btn_cfields_display_order = "Сохранить порядок показа";
$TLS_btn_unassign = "Освободить от";
$TLS_cfields_active = "Активный";
$TLS_cfields_tproject_assign = "Привязать пользовательские поля";
$TLS_display_order = "Порядок показа";
$TLS_title_assigned_cfields = "Привязанные пользовательские поля";
$TLS_title_available_cfields = "Доступные пользовательские поля";
</code-php>

==gui/templates/usersview.tpl==
<code-php>
$TLS_No = "Нет";
$TLS_Yes = "Да";
$TLS_alt_delete_user = "Действительно удалить выбранного пользователя?";
$TLS_alt_edit_user = "Править пользователя";
$TLS_order_by_login = "По порядку логинов";
$TLS_order_by_role_descr = "По порядку описания ролей";
$TLS_th_active = "Активный";
$TLS_th_delete = "Удалить?";
$TLS_th_email = "Email";
$TLS_th_first_name = "Имя";
$TLS_th_last_name = "Фамилия";
$TLS_th_locale = "Локализация";
$TLS_th_login = "Логин";
$TLS_th_role = "Роль";
$TLS_warning_delete_user = "Действительно удалить выбранного пользователя?";
</code-php>

==gui/templates/login.tpl==
<code-php>
$TLS_btn_login = "Войти";
$TLS_login_name = "Логин:";
$TLS_lost_password_q = "Забыли пароль?";
$TLS_new_user_q = "Новый пользователь?";
$TLS_password = "Пароль:";
</code-php>

==gui/templates/loginFirst.tpl==
<code-php>
$TLS_btn_add_user_data = "Добавить пользовательские данные";
$TLS_e_mail = "E-mail (нужен, чтобы получить новый пароль):";
$TLS_first_name = "Имя:";
$TLS_last_name = "Фамилия:";
$TLS_link_back_to_login = "Войти еще раз";
$TLS_password_again = "Повторите пароль:";
$TLS_password_mgmt_is_external = "Используется внешнее управление паролями";
</code-php>

==gui/templates/tcMove.tpl==
<code-php>
$TLS_btn_mv = "Переместить";
$TLS_choose_cat = "Выберите группу тестов";
$TLS_inst_move = "Переместить этот тест в другую группу тестов (внутри того же плана тестирования).";
$TLS_title_mv_cp_tc = "Переместить/Копировать тест";
</code-php>

==gui/templates/loginLost.tpl==
<code-php>
$TLS_btn_send = "Выслать пароль";
$TLS_password_reset = "Сбросить пароль";
</code-php>

==gui/templates/tcView.tpl==
<code-php>
$TLS_no_records_found = "Ничего не найдено.";
</code-php>

==gui/templates/execSetResults.tpl==
<code-php>
$TLS_alt_attachment_mgmt = "вложения";
$TLS_alt_notes = "заметки";
$TLS_attachment_mgmt = "вложения";
$TLS_btn_history_off = "Показывать только последний прогон";
$TLS_btn_history_on = "Показывать полную историю прогонов";
$TLS_btn_save_all_tests_results = "Сохранить все результаты прогонов";
$TLS_btn_save_tc_exec_results = "Сохранить результат прогона";
$TLS_bug_mgmt = "Управление багами";
$TLS_build_is_closed = "Сборка закрыта";
$TLS_builds_notes = "Описание сборки";
$TLS_bulk_tc_status_management = "Массовое управление состоянием тестов";
$TLS_date_time_run = "Дата";
$TLS_details = "Подробности";
$TLS_exec_notes = "Заметки";
$TLS_exec_status = "Состояние";
$TLS_execution_history = "История прогонов";
$TLS_img_title_bug_mgmt = "Управление багами";
$TLS_img_title_delete_execution= "Удалить прогон";
$TLS_just_last_execution_for_this_build = "Последний прогон для этой сборки";
$TLS_no_data_available = "Данные отсутствуют";
$TLS_set_all_tc_to = "Установить всем состояние ";
$TLS_show_hide = "Показать / скрыть";
$TLS_tc_not_tested_yet = "Еще не протестировано:";
$TLS_test_cases_cannot_be_executed = "Тесты не могут быть выполнены";
$TLS_test_exec_by = "Протестировано: ";
$TLS_test_exec_expected_r = "Ожидаемые результаты";
$TLS_test_exec_last_run_date = "Самые последние запуски:";
$TLS_test_exec_notes = "Заметки / Описание";
$TLS_test_exec_on_build = " в Сборке";
$TLS_test_exec_result = "Результат";
$TLS_test_exec_steps = "Шаги";
$TLS_test_exec_summary = "Резюме";
$TLS_test_plan_notes = "Заметки по плану тестирования";
$TLS_test_status_not_run = "Не запущен";
$TLS_th_test_case_id = "ID ";
$TLS_th_testsuite = "Группа тестов";
$TLS_title_t_r_on_build = "Результы тестов по Сборке";
$TLS_title_t_r_owner = " Ответственный:";
$TLS_title_test_case = "Тест";
$TLS_version = "Версия";
</code-php>

==gui/templates/inc_testsuite_viewer_ro.tpl==
<code-php>
$TLS_keywords = "Ключевые слова";
$TLS_test_suite = "Группа тестов";
</code-php>

==gui/templates/navBar.tpl==
<code-php>
$TLS_home = "Домой";
$TLS_link_logout = "Выход";
$TLS_product = "Проект";
$TLS_product_role = "Роль проекта";
$TLS_title_edit_personal_data = "Мой профиль";
$TLS_title_execute = "Выполнить";
$TLS_title_results = "Отчеты";
$TLS_title_specification = "Спецификация";
</code-php>

==gui/templates/inc_testsuite_viewer_rw.tpl==

==gui/templates/planAddTC_m1.tpl==
<code-php>
$TLS_add_tc = "Добавить";
$TLS_add_remove_selected_tc_hint = "Операция будет выполнена над ВСЕМИ группами тестов";
$TLS_btn_add_remove_selected_tc = "Добавить / Удалить выбранное";
$TLS_btn_add_selected_tc = "Добавить выбранное";
$TLS_btn_check = "Отметить";
$TLS_btn_uncheck = "Снять отметки";
$TLS_check_uncheck_tc = "Все тесты в этой группе тестов.";
$TLS_check_uncheck_all_checkboxes="отметить все/снять все отметки";
$TLS_has_been_executed = "были выполнены";
$TLS_inactive_testcase = "неактивны";
$TLS_no_testcase_available = "Тестов нет";
$TLS_note_keyword_filter = "Тесты фильтруются по ключевому слову";
$TLS_remove_tc = "Удалить";
$TLS_th_test_case = "Тест";
$TLS_title_add_remove_test_to_plan = "Добавить/Удалить тест(ы) в/из плана тестирования";
$TLS_title_add_test_to_plan = "Добавить тесты в план тестирования";
$TLS_warning_add_remove_selected_tc = "Вы уверены удалить выбранные тесты из этого плана тестирования?";
</code-php>

==gui/templates/planAddTCNavigator.tpl==
<code-php>
$TLS_title_navigator = "Навигатор";
</code-php>

==gui/templates/planPriority.tpl==
<code-php>
$TLS_btn_upd_prio = "Сохранить";
$TLS_title_priority = "Определить приоритеты для плана тестирования";
$TLS_tr_th_importance = "Важность";
$TLS_tr_th_prio_cba = "Приоритет (C/B/A)";
$TLS_tr_th_risk = "Риск/Важность";
</code-php>

==gui/templates/planEdit.tpl==
<code-php>
$TLS_btn_testplan_create = "Создать";
$TLS_cancel = "Отменить";
$TLS_opt_no = "Нет";
$TLS_testplan_question_create_tp_from = "Создать из существующего плана тестирования?";
$TLS_testplan_th_active = "Активный";
$TLS_testplan_th_name = "Имя";
$TLS_testplan_th_notes = "Описание";
$TLS_testplan_title_create = "Создать новый план тестирования";
$TLS_testplan_title_edit = "Править план тестирования";
$TLS_testplan_title_for_project = "для проекта: ";
$TLS_testplan_title_tp_management = "Управление планами тестирования";
$TLS_testplan_txt_notes = <<<END
План тестирования должен содержать ясно определенные задачи, включая временные границы.
Он может содержать тест-активность для выпускаемой версии продукта (включая патчи)
или просто единственный запрос от пользователя.<br/>
В описании можно ссылаться на план и другую документацию по проекту.
Разумно перечислить тестируемые возможности, риски и т.п.<br/>
Можно создать новый план тестирования из существующего ("клонировать").
Будут скопированы следующие элементы: сборки, тесты, приоритеты,
Вехи и роли пользователей.<br/>
План тестирования можно деактивировать/заморозить: т.е. запретить любое изменение
атрибутов или вложенных элементов плана тестирования.
Такие планы тестирования будут видны только на странице отчетов и на этой странице.
END;

$TLS_warning_empty_tp_name = "Пожалуйста, введите имя плана тестирования.";
</code-php>

==gui/templates/planNew.tpl==
<code-php>
$TLS_testplan_btn_edit = "Сохранить";
$TLS_testplan_btn_new = "Создать";
$TLS_testplan_menu_create = "Создать";
$TLS_testplan_menu_edit = "Править";
$TLS_testplan_menu_list = "Список";
</code-php>

==gui/templates/planMilestones.tpl==
<code-php>
$TLS_alt_delete_milestone = "Удалить веху?";
$TLS_btn_edit_milestone = "Править";
$TLS_btn_new_milestone = "Создать";
$TLS_info_milestones_date = "Веха не может иметь дату раньше чем 'сегодня'";
$TLS_no_milestones = "Для этого плана тестирования вехи не определены.";
$TLS_popup_delete_milestones = "Вы уверены удалить веху %NAME% ?";
$TLS_warning_empty_milestone_name="Укажите имя вехи!";

$TLS_th_date_format = "Целевая Дата";
$TLS_th_perc_a_prio = "% A-приоритет";
$TLS_th_perc_b_prio = "% B-приоритет";
$TLS_th_perc_c_prio = "% C-приоритет";
$TLS_title_existing_milestones = "Существующие вехи";
$TLS_title_milestones = "Вехи для плана тестирования";
$TLS_title_new_milestone = "Новая Веха";
</code-php>

==gui/templates/projectedit.tpl==
<code-php>
$TLS_btn_activate = "Активировать";
$TLS_btn_del = "Удалить";
$TLS_btn_edit_del = "Править / Удалить";
$TLS_btn_inactivate = "Деактивировать";
$TLS_caption_edit_product = "Править проект";
$TLS_caption_new_product = "Создать проект";
$TLS_color = "Цвет";
$TLS_enable_requirements = "Включить функциональность Требований";
$TLS_info_failed_loc_prod = "Не удалось локализовать проект.";
$TLS_notes = "Заметки";
// Warning!!! - if JS string you must use \\n to get \n
$TLS_popup_product_delete = <<<END
Внимание! Вы собираетесь необратимо удалить все данные связанные проектом:
результаты тестов, планы тестирования, тесты и т.п. \\n
Вместо удаления вы можете деактивировать проект. \\n
Если вы всё-таки настроены удалить проект, рекомендуем вам сначала
сделать бэкап базы данных. \\n
Итак, вы по прежнему уверены удалить проект?
END;
$TLS_warning_empty_tproject_name = "Обязательно задайте имя проекта!";
</code-php>

==gui/templates/reqAssign.tpl==
<code-php>
$TLS_please_select_a_req = "Пожалуйста, выберите требование";
$TLS_req_msg_norequirement66 = "Требования нет";
$TLS_req_title_assign = "Привяжите требования к тесту";
$TLS_req_title_assigned = "Привязанные требования";
$TLS_req_title_unassigned = "Доступные требования";
$TLS_warning_req_tc_assignment_impossible = <<<END
<p>
Вы <b>не можете</b> делать привязку по одной из следующих причин:
<ul>
<li>Не определено ни одной спецификации требования;
<li>Спецификации требований пусты.
</ul>
END;
</code-php>

==gui/templates/tcEdit.tpl==
<code-php>
$TLS_title_edit_tc = "Править тест";
$TLS_warning_editing_executed_tc = "Внимание: Этот версия теста уже выполнялась";
</code-php>

==gui/templates/planOwner.tpl==
<code-php>
$TLS_assign_ownership = "Назначить ответственного";
$TLS_def_prio_rules = "Определить правила приоритетов";
$TLS_opt_label_none = "нет";
$TLS_th_imp = "Важность";
$TLS_th_owner = "Тестировщик";
$TLS_th_risk = "Риск";
$TLS_th_test_suite = "Группа тестов";
$TLS_title_plan_ownership = "Владелец плана тестирования";
</code-php>

==gui/templates/tcView_viewer.tpl==
<code-php>
$TLS_activate_this_tcversion = "Активировать эту версию";
$TLS_Requirements = "Требования";
$TLS_btn_del_this_version = "Удалить эту версию";
$TLS_btn_edit = "Править";
$TLS_btn_mv_cp = "Переместить/Копировать";
$TLS_btn_new_version = "Создать новую версию";
$TLS_can_not_edit_tc = "Вы не можете редактировать эту версию, т.к. она уже выполнялась";
$TLS_deactivate_this_tcversion = "Деактивировать эту версию";
$TLS_tcversion_is_inactive_msg = "Эта версия <b>неактивна</b>, и не будет доступна для включения в план тестирования";
</code-php>

==gui/templates/planRemoveTC_m1.tpl==
<code-php>
$TLS_btn_remove_selected_tc = "Удалить выбранные тесты tcs";
$TLS_remove_ok = "Удаление прошло успешно ok";
$TLS_title_remove_test_from_plan = "Удалить тест из плана тестирования";
</code-php>

==gui/templates/planTesters.tpl==
<code-php>
$TLS_btn_save = "Сохранить";
</code-php>

==gui/templates/keywordsAssign.tpl==
<code-php>
$TLS_keyword_assignment_empty_tsuite = "В этой группе тестов нет тестов => ключевое слово привязать нельзя";
$TLS_menu_assign_kw_to_tc = "Привязать к тестам";
$TLS_menu_manage_keywords = "Управление ключевыми словами";
$TLS_title_keywords = "Ключевые слова";
</code-php>

==gui/templates/planTestersNavigator.tpl==
<code-php>
$TLS_label_list_of = "Список ";
$TLS_opt_test_plans = "планов тестирования";
$TLS_opt_users = "пользователей";
</code-php>

==gui/templates/planUpdateTC.tpl==
<code-php>
$TLS_btn_upd_ck_tc = "Изменить выбранные тест(ы)";
$TLS_info_all_tc_uptodate = "Все тесты актуальны.";
$TLS_th_category = "Группа тестов";
$TLS_th_component = "Группа тестов";
$TLS_th_id_tc = "[ID] теста";
$TLS_th_reason = "Причина правки";
$TLS_th_spec_version = "Специальная версия";
$TLS_th_status = "Состояние";
$TLS_th_suite_version = "Версия группы тестов";
$TLS_th_update = "Изменить";
$TLS_title_upd_mod_tc = "Изменить исправленные тесты в ";
</code-php>

==gui/templates/keywordsView.tpl==
<code-php>
$TLS_alt_delete_keyword = "Удалить ключевое слово?";
$TLS_btn_create_keyword = "Создать ключевое слово";
$TLS_btn_edit_keyword = "Править";
$TLS_btn_import_keywords = "Импорт";
$TLS_th_keyword = "Ключевое слово";
$TLS_warning_delete_keyword = "Вы уверены удалить ключевое слово?";
$TLS_warning_enter_at_least1 = "Пожалуйста, введите хотя бы ";
$TLS_warning_enter_at_least2 = " символов.";
$TLS_warning_enter_less1 = "Пожалуйста, используйте не больше чем";
$TLS_warning_enter_less2 = " символов.";
</code-php>

==gui/templates/reqexport.tpl==
<code-php>
$TLS_title_req_export_to = "Экспорт требований";
</code-php>

==gui/templates/resultsAllBuilds.tpl==
<code-php>
$TLS_test_status_blocked = "Блокирован";
$TLS_test_status_failed = "Сбой";
$TLS_test_status_passed = "Пройден";
$TLS_th_build = "Сборка";
$TLS_th_tc_total = "Всего тестов";
</code-php>

==gui/templates/resultsBugs.tpl==
<code-php>
$TLS_date = "Дата:";
$TLS_printed_by = "Напечатано:";
$TLS_title_test_case_bugs = "Баги по тесту";
$TLS_title_test_case_timestamp = "Временная метка теста";
$TLS_title_test_case_title = "Заголовок теста";
$TLS_title_test_suite_name = "Имя группы тестов";
</code-php>

==gui/templates/resultsBuild.tpl==
<code-php>
$TLS_title_met_of_build = "Метрики сборки";
</code-php>

==gui/templates/resultsByStatus.tpl==
<code-php>
$TLS_info_test_results = <<<END
<p>
Показываются результаты только последнего теста.
<p>
В частности, тесты скрыты, если результаты тестов для следующей сборки
имеют статус отличный от "в процессе".
END;

$TLS_th_bugs = "Баги";
$TLS_th_date = "Дата";
$TLS_th_run_by = "Запустил:";
</code-php>

==gui/templates/resultsGeneral.tpl==
<code-php>
$TLS_title_gen_test_rep = "Общие метрики плана тестирования";
</code-php>

==gui/templates/resultsMoreBuilds_query_form.tpl==
<code-php>
$TLS_excel_format = "MS Excel";
$TLS_html_format = "HTML";
$TLS_last_status_any = "Любой";
$TLS_last_status_blocked = "Блокирован";
$TLS_last_status_failed = "Сбой";
$TLS_last_status_not_run = "Не стартовал";
$TLS_last_status_passed = "Пройден";
$TLS_select_builds_header = "Выберите сборку(и)";
$TLS_select_components_header = "Выберите группу тестов";
$TLS_select_keyword_header = "Выберите ключевое слово";
$TLS_select_last_result_header = "Выберите последний результат";
$TLS_select_owner_header = "Выберите владельца";
$TLS_select_report_format_header = "Выберите формат отчета";
$TLS_submit_query = "Выполнить запрос";
$TLS_test_plan_header = "План тестирования: ";
$TLS_query_metrics_report = "Запросить отчет по метрикам";
$TLS_enter_start_time = "Введите начальное время";
$TLS_enter_end_time = "Введите конечное время";
$TLS_year = "год";
$TLS_month = "месяц";
$TLS_day = "день";
$TLS_hour = "час";
$TLS_search_in_notes = "поиск строки в заметках";
$TLS_executor = "исполнитель";
</code-php>

==gui/templates/resultsMoreBuilds_report.tpl==
<code-php>
$TLS_caption_show_collapse = "Показать/Свернуть";
$TLS_caption_user_selected_query_parameters = "Параметры запроса";
$TLS_not_yet_executed = "Еще не выполнялся";
$TLS_show_hide_all = "Показать/Скрыть все";
$TLS_th_builds = "Сборка(и)";
$TLS_th_execution_ts = "Время";
$TLS_th_last_result = "Последний результат";
$TLS_th_report_format = "Тип отчета";
$TLS_th_test_plan = "План тестирования";
$TLS_th_test_suites = "Группа(ы) тестов";
$TLS_th_tester_id = "Тестировщик";
$TLS_th_total_block = "# блокированных ";
$TLS_th_total_cases = "# тестов";
$TLS_th_total_fail = "# сбоев";
$TLS_th_total_not_run = "# не стартовавших";
$TLS_th_total_pass = "# выполненных";
$TLS_th_start_time = "Время начала";
$TLS_th_end_time = "Время окончания";
$TLS_th_executor = "Исполнитель";
$TLS_th_search_notes_string = "в заметках искать строку";
$TLS_true = "да";
$TLS_false = "нет";
$TLS_display_suite_summaries = "Показать итоги по группе тестов";
$TLS_display_query_params = "Показать параметры запроса";
$TLS_display_totals = "Показать суммарную информацию";
</code-php>

==gui/templates/resultsReqs.tpl==
<code-php>
$TLS_req_title_blocked = "Заблокировано требований";
$TLS_req_title_failed = "Нарушено требований";
$TLS_req_title_notrun = "Непроверенных требований";
$TLS_req_title_passed = "Выполнено требований";
$TLS_title_result_req_testplan = "Результаты тестов основанных на спецификации требований";
$TLS_title_test_plan = "План тестирования";
</code-php>

==gui/templates/resultsSend.tpl==
<code-php>
$TLS_btn_send_report = "Послать отчет";
$TLS_check_send_to_me = "Послать отчет самому себе";
$TLS_mail_body = "Тело письма:";
$TLS_mail_report = "Отчет:";
$TLS_mail_subject = "Тема письма:";
$TLS_mail_to = "Кому:";
$TLS_status_for_build = "Состояние сборки";
$TLS_tp_status = "Общее состояние плана тестирования";
$TLS_tp_status_for_build = "Состояние плана тестирования для сборки";
</code-php>

==gui/templates/resultsTC.tpl==
<code-php>
$TLS_generated_by_TestLink_on="Сформировано системой TestLink, ";
</code-php>

==gui/templates/tcEdit_m2.tpl==

==gui/templates/tcPrintNavigator.tpl==
<code-php>
$TLS_caption_print_opt = "Настройки печати";
$TLS_tr_td_show_as = "Показать как";
</code-php>

==gui/templates/tcReorder.tpl==
<code-php>
$TLS_no_tc_to_reorder = "Нет тестов для переупорядочивания.";
$TLS_title_change_tc_order = "Изменить порядок тестов в этой группе тестов.";
</code-php>

==gui/templates/tcTree.tpl==
<code-php>
$TLS_button_refresh = "Обновить";
$TLS_button_update_tree = "Обновить дерево";
$TLS_do_auto_update = "Обновлять дерево после каждой операции";
$TLS_no_tc_spec_av = "Нет тест-спецификаций.";
</code-php>

==gui/templates/tc_exec_assignment.tpl==
<code-php>
$TLS_btn_do = "Пуск";
$TLS_btn_update_selected_tc = "Изменить выбранные тесты";
$TLS_title_tc_exec_assignment = "Назначить прогоны тестов для плана тестирования ";
$TLS_user = "Пользователь";
$TLS_user_bulk_assignment = "Массовое назначение ответственных пользователей";
</code-php>

==gui/templates/testSetNavigator.tpl==

==gui/templates/userInfo.tpl==
<code-php>
$TLS_btn_change_passwd = "Сменить пароль";
$TLS_btn_upd_user_data = "Изменить";
$TLS_th_new_passwd = "Новый пароль";
$TLS_th_new_passwd_again = "Повторите новый пароль";
$TLS_th_old_passwd = "Старый пароль";
$TLS_title_account_settings = "Настройки профиля";
$TLS_title_change_your_passwd = "Сменить ваш пароль";
$TLS_warning_different_pwd = "Пожалуйста, повторите еще раз ваш новый пароль. Введенные пароли не совпадают.";
$TLS_warning_empty_pwd = "Пароль должен быть не пуст!";
$TLS_your_password_is_external = "Ваш пароль ведётся во внешней системе";
</code-php>

==gui/templates/usersassign.tpl==
<code-php>
$TLS_TestProject = "проект";
$TLS_User = "Пользователь";
$TLS_btn_change = "Изменить";
$TLS_caption_assign_testplan_user_roles = "Назначить роли плана тестирования пользователям";
$TLS_caption_assign_testproject_user_roles = "Назначить роли проекта пользователям";
$TLS_menu_assign_testproject_roles = "Назначить роли проекта";
$TLS_th_roles = "Роли";
$TLS_title_assign_roles = "Назначить роли";
</code-php>

==gui/templates/usersedit.tpl==
<code-php>
$TLS_button_reset_password = "Сбросить пароль";
$TLS_caption_user_details = "Свойства пользователя";
$TLS_th_password = "Пароль";
$TLS_warning_empty_first_name = "Пожалуста, введите имя";
$TLS_warning_empty_last_name = "Пожалуйста, введите фамилию";
$TLS_warning_empty_login = "Пожалуйста, введите логин";
</code-php>

==gui/templates/attachmentupload.tpl==
<code-php>
$TLS_attachment_upload_ok="Файл загружен.";
$TLS_enter_attachment_title = "Введите заголовок для этого вложения.";
$TLS_import_was_ok = "Импорт прошел успешно.";
$TLS_max_size_cvs_file = "Максимальный размер файла:";
$TLS_title_upload_attachment = "Загрузить вложение";
</code-php>

==gui/templates/rolesview.tpl==
<code-php>
$TLS_N_A = "N/A";
$TLS_alt_delete_role = "Удалить роль";
$TLS_alt_edit_role = "Править роль";
$TLS_btn_confirm_delete = "Удалить";
$TLS_no_roles = "Нет ролей";
$TLS_title_roles = "Доступные роли";
$TLS_warning_users_will_be_reset = "'Задетым пользователям' будет назначена гостевая роль!";
</code-php>

==gui/templates/tcexport.tpl==
<code-php>
$TLS_export_with_keywords = "Экспортировать с ключевыми словами";
</code-php>

==gui/templates/buildView.tpl==
<code-php>
$TLS_alt_active_build = "Активная сборка";
$TLS_alt_edit_build = "Редактировать эту сборку";
$TLS_alt_open_build = "Открыть сборку";
$TLS_btn_build_create = "Создать";
$TLS_no_builds = "В этот плане тестирования сборок не определено.";
$TLS_th_description = "Описание";
$TLS_th_open = "Открыть";
$TLS_title_build_list = "Список существующих сборок";
$TLS_warning_delete_build = <<<END
<p>Вы действительно хотите уничтожить эту сборку? <p>
Все связанные данные (в частности, результаты тестов) будут также удалены!";
END;
</code-php>

==gui/templates/planView.tpl==
<code-php>
$TLS_testplan_alt_delete_tp = "Удалить этот план тестирования?";
$TLS_testplan_alt_edit_tp = "Править план тестирования";
$TLS_testplan_msg_delete_confirm = <<<END
Вы уверены, что хотите удалить план тестирования? <p>
План тестирования можно деактивировать не удаляя.
END;

$TLS_testplan_th_delete = "Удалить";
$TLS_testplan_title_list = "Список планов тестирования";
$TLS_testplan_txt_empty_list = <<<END
Ни одного плана тестирования не определено! <p>
Чтобы воспользоваться функциональностью прогонов тестов, нужно
создать хотя бы один.
END;
$TLS_alt_active_testplan = "Активный план тестирования";
</code-php>

==gui/templates/mainPage_left.tpl==
<code-php>
$TLS_href_assign_user_roles = "Назначить пользовательские роли";
$TLS_href_browse_tc = "Просмотр тестов";
$TLS_href_cfields_management = "Управление пользовательскими полями";
$TLS_href_cfields_tproject_assign = "Привязка пользовательских полей";
$TLS_href_create_product = "Создать новый проект";
$TLS_href_edit_product = "Править/Удалить проект";
$TLS_href_edit_tc = "Редактировать тесты";
$TLS_href_keywords_assign = "Привязать ключевые слова";
$TLS_href_keywords_manage = "Управление ключевыми словами";
$TLS_href_keywords_view = "Просмотр ключевых слов";
$TLS_href_print_tc = "Печать тестов";
$TLS_href_req_assign = "Привязать требования";
$TLS_href_req_spec = "Спецификация требований";
$TLS_href_roles_management = "Управление ролями";
$TLS_href_search_tc = "Искать тест(ы)";
$TLS_href_user_management = "Управление пользователями";
$TLS_title_requirements = "Требования";
$TLS_title_test_spec = "Спецификации тестов";
$TLS_title_product_mgmt = "Управление проектами";
</code-php>

==gui/templates/mainPage_right.tpl==
<code-php>
$TLS_filter_tp_by_product = "Фильтровать план тестирования по проектам";
$TLS_href_add_test_case = "Добавить тест(ы)";
$TLS_href_build_new = "Управление сборками";
$TLS_href_execute_test = "Выполнить тесты";
$TLS_href_plan_assign_priority = "Установить приоритеты";
$TLS_href_plan_define_priority = "Определить правила приоритетов";
$TLS_href_plan_management = "Управление планами тестирования";
$TLS_href_plan_mstones = "Управление вехами";
$TLS_href_print_tc_suite = "Печать плана тестирования";
$TLS_href_remove_test_case = "Удалить тест(ы)";
$TLS_href_rep_and_metrics = "Отчеты и метрики";
$TLS_href_tc_exec_assignment = "Поручить прогон тестов";
$TLS_href_upd_mod_tc = "Сохранить измененные тесты";
$TLS_msg_no_rights_for_tp = "- недоступен (У вас нет доступа ни для одного плана тестирования)";
$TLS_testplan_role = "Роль плана тестирования";
$TLS_title_test_case_suite = "Содержание плана тестирования";
$TLS_title_test_execution = "Выполнение плана тестирования";
$TLS_title_test_plan_mgmt = "Управление планами тестирования";
$TLS_href_newest_tcversions = "Показать тесты с самыми свежими версиями";
</code-php>

==lib/execute/bug_add.php==
<code-php>
$TLS_bug_added = "Баг добавлен";
$TLS_error_bug_does_not_exist_on_bts="Бага с таким ID не зарегистрировано в BTS!";
$TLS_error_wrong_BugID_format = "Неверный формат BugID!";
</code-php>

==lib/execute/bug_delete.php==
<code-php>
$TLS_bugdeleting_was_ok = "Баг успешно удален.";
</code-php>

==lib/functions/doAuthorize.php==
<code-php>
$TLS_error_ldap_auth_failed = "LDAP-аутентификация не удалась";
$TLS_error_ldap_bind_failed = "Не удалось выполнить LDAP-binding";
$TLS_error_ldap_server_connect_failed = "Не удалось соединится с LDAP-сервером";
$TLS_error_ldap_update_failed = "Обновление LDAP не удалось";
$TLS_error_ldap_user_not_found = "LDAP-пользователь не найден";
</code-php>

==lib/functions/product.inc.php==
<code-php>
$TLS_info_product_delete_fails = "При удалении этого проекта произошла ошибка";
</code-php>

==lib/functions/results.inc.php==
<code-php>
$TLS_trep_failing = "Провалены";
$TLS_trep_passing = "Прошли";
$TLS_trep_status_for_build = "Состояние для сборки";
$TLS_trep_status_for_ts = "Состояние для группы тестов";
$TLS_unassigned = "Не назначены";
</code-php>

==lib/functions/resultsMoreBuilds.inc.php==
<code-php>
$TLS_bugs = "Связанные Баги";
$TLS_builds_selected = "Сборка(и)";
$TLS_case_not_run_warning = "Тест не запущен";
$TLS_category_header = "Группа тестов =";
$TLS_daterun = "Дата запуска";
$TLS_last_status = "Последнее состояние";
$TLS_number_blocked = "# блокированных";
$TLS_number_cases = "# тестов";
$TLS_number_executions = "# тест-пусков";
$TLS_number_failed = "# тест-сбоев";
$TLS_number_not_run = "# не запущено";
$TLS_number_passed = "# пройденных";
$TLS_owner = "Тестировщик";
$TLS_owner_header = "Tester =";
$TLS_runby = "Запущен тестировщиком ";
$TLS_test_plan_name = "План тестирования";
</code-php>

==lib/functions/roles.inc.php==
<code-php>
$TLS_desc_cfield_management = "Управление пользовательскими полями";
$TLS_desc_cfield_view = "Просмотр пользовательских полей (read-only)";
$TLS_desc_mgt_modify_key = "Управление ключевыми словами";
$TLS_desc_mgt_modify_product= "Управление проектами";
$TLS_desc_mgt_modify_req = "Управление требованиями";
$TLS_desc_mgt_modify_tc = "Создание/правка тестов";
$TLS_desc_mgt_modify_users = "Управление пользователями";
$TLS_desc_mgt_view_key = "Просмотр ключевых слов (read-only)";
$TLS_desc_mgt_view_req = "Просмотр требований (read-only)";
$TLS_desc_mgt_view_tc = "Просмотр тестов (read-only)";
$TLS_desc_role_management = "Управление ролями";
$TLS_desc_testplan_create_build = "Создание/редактирование сборки";
$TLS_desc_testplan_execute = "Выполнение плана тестирования";
$TLS_desc_testplan_metrics = "Метрики плана тестирования";
$TLS_desc_testplan_planning = "Составление плана тестирования";
$TLS_desc_user_role_assignment = "Назначение ролей";
$TLS_error_duplicate_rolename = "Роль с таким именем уже есть!";
$TLS_error_role_no_rights = "Вы не можете создать роль без каких-либо прав!";
$TLS_error_role_no_rolename = "Вам нужно ввести имя для этой роли.";
$TLS_mgt_testplan_create = "Создать/править план тестирования";
</code-php>

==lib/functions/testproject.class.php==
<code-php>
$TLS_error_creating_req_spec = "Ошибка при создании спецификации требования";
$TLS_info_product_name_empty = "Нельзя давать пустое имя.";
$TLS_keyword_already_exists = "Такое ключевое слово уже есть";
$TLS_string_contains_bad_chars = "Введенная строка содержит недопустимые символы.";
$TLS_warning_duplicate_req_title= "Требование с таким заголовком уже есть.";
</code-php>

==lib/functions/requirements.inc.php==
<code-php>
$TLS_conflict = "Конфликт";
$TLS_error_deleting_req = "Ошибка при удалении требования(й).";
$TLS_error_inserting_req = "Ошибка при вставке требования(й).";
$TLS_error_updating_req = "Ошибка при правке требования(й).";
$TLS_error_updating_reqspec = "Ошибка при правке спецификаций требований.";
$TLS_file_is_not_xml = "Файл не распознан как корректный XML, и не может быть использован.";
$TLS_ok = "OK";
$TLS_req_import_format_description1 = " - тип CSV требует три поля на каждую запись: 'req_doc_id','title','description'";
$TLS_req_import_format_description2 = " - CSV, экспортированный из DOORS требует запись-заголовок.";
$TLS_req_import_result_overwritten = "перезаписано!";
$TLS_req_import_result_skipped = "пропущено";
$TLS_req_state_not_testable = "не тестируемо";
$TLS_req_state_valid = "актуально";
$TLS_the_format_req_xml_import = "Неверный XML-формат для импорта требований";
$TLS_warning_duplicate_reqdoc_id = "Не уникальный (дублирующий) id документа";
</code-php>

==lib/functions/testsuite.class.php==
<code-php>
$TLS_component_name_already_exists = "Группа тестов с таким именем уже зарегистрирована";
$TLS_testsuite = "Группа тестов";
</code-php>

==lib/functions/exec.inc.php==
<code-php>
$TLS_test_results_submitted = "Результаты тестов отправлены.";
</code-php>

==lib/functions/print.inc.php==
<code-php>
$TLS_author = "Автор";
$TLS_printed_by_TestLink_on = "Распечатано TestLink'ом ";
$TLS_title_toc = "Содержание";
$TLS_passfail = "Пройден / Провален";
$TLS_testnotes = "Заметки к тесту";
</code-php>

==lib/functions/testcase.class.php==
<code-php>
$TLS_testcase_name_already_exists = "Тест с таким именем уже есть!";
$TLS_the_format_tc_xml_import = "";
</code-php>

==lib/functions/info.inc.php==
<code-php>
$TLS_email_sent_message = "Ваше письмо отослано.";
</code-php>

==lib/functions/users.inc.php==
<code-php>
$TLS_Unknown = "Неизвестно";
$TLS_duplicate_login = "Пользователь с таким логином уже есть!";
$TLS_login_must_not_be_empty = "Логин не должен быть пустым!";
$TLS_wrong_old_password = "Старый пароль неверен!";
</code-php>

==lib/functions/email_api.php==
<code-php>
$TLS_stmp_host_unconfigured = "Некорректно указан SMTP host!";
</code-php>

==lib/functions/common.php==

==lib/functions/configCheck.php==
<code-php>
$TLS_attachments_dir = "каталог для вложений:";
$TLS_bts_connection_problems = <<<END
Не удалось соединиться с вашей Bug Tracking System.<p>
Пожалуйста, проверьте настройки.<p>
Будьте внимательны, эта проблема
снижает производительность TestLink'а.
END;

$TLS_but_directory_is_not_writable = "Каталог закрыт для записи!";
$TLS_directory_is_writable = "Каталог открыт для записи.";
$TLS_does_not_exist = "не существует";
$TLS_exists = "существует";
$TLS_ldap_extension_not_loaded=<<<END
Метод аутентификации указан как LDAP </br>
однако PHP/LDAP extension не загружено =>
Вам не удастся войти в систему.
Пожалуйста, свяжитесь с администратором TestLink'а.
END;
$TLS_sec_note_admin_default_pwd = "Вам необходимо сменить пароль по умолчанию у пользователя 'admin'!";
$TLS_sec_note_remove_install_dir = "Инсталляционный каталог должен быть удален!";
</code-php>

==lib/general/frmWorkArea.php==
<code-php>
$TLS_create_a_build = "Создать новую сборку";
$TLS_no_build_warning_part1 = "Ни одной сборки для этого тест плана не создано.";
$TLS_no_build_warning_part2 = "Создайте их или попросите об этом свое руководство.";
</code-php>

==lib/general/myTPInfo.php==
<code-php>
$TLS_no_testplans_available = "К сожалению, ни одного плана тестирования не доступно";
</code-php>

==lib/general/tlsmarty.inc.php==

==lib/keywords/keywords.inc.php==
<code-php>
$TLS_empty_keyword_no = "Ключевое слово должно быть непустым!";
$TLS_keywords_char_not_allowed = "Запятые и кавычки недопустимы в ключевых словах!";
$TLS_tc_kw_update_fails1 = "Тест";
$TLS_tc_kw_update_fails2 = " дал сбой ";
$TLS_the_format_keyword_csv_import = "keyword;notes";
$TLS_the_format_keyword_xml_import = "<keywords><keyword name=\"name\">Notes</keyword></keywords>";
</code-php>

==lib/keywords/keywordsView.php==
<code-php>
$TLS_kw_delete_fails = "Не удалось удаление ключевого слова!";
$TLS_kw_update_fails = "Не удалась правка ключевого слова!";
</code-php>

==lib/keywords/keywordsAssign.php==
<code-php>
$TLS_assigned_kword = "Связанные ключевые слова";
$TLS_available_kword = "Доступные ключевые слова";
</code-php>

==lib/plan/buildNew.php==
<code-php>
$TLS_cannot_add_build = "Невозможно добавить сборку!";
$TLS_cannot_delete_build = "Невозможно удалить сборку!";
$TLS_cannot_update_build = "Ошибка при правке сборки!";
$TLS_warning_duplicate_build = "Сборка с таким идентификатором уже есть.";
</code-php>

==lib/plan/plan.inc.php==
<code-php>
$TLS_warning_empty_milestone_name = "Обязательно введите имя для вехи!";
$TLS_warning_enter_valid_date = "Введенная дата некорректна!";
$TLS_warning_invalid_percentage_value = "Значения-проценты должны быть от 0 to 100 (%)";
$TLS_warning_milestone_date = "Веха не может иметь дату раньше чем 'сегодня'!";
$TLS_warning_percentage_value_higher_than_100 = "Сумма всех значений-процентов не должна быть больше 100!";
</code-php>

==lib/plan/planMilestones.php==
<code-php>
$TLS_milestone_delete_fails = "Не удалось удалить веху!";
$TLS_warning_milestone_add_failed = "Не удалось добавить веху!";
$TLS_warning_milestone_update_failed = "Не удалось править веху!";
</code-php>

==lib/plan/planOwner.php==
<code-php>
$TLS_opt_imp_high = "Высокая";
$TLS_opt_imp_low = "Низкая";
$TLS_opt_imp_medium = "Средняя";
</code-php>

==lib/plan/planTestersEdit.php==
<code-php>
$TLS_title_assign_tp = "Поручить планы тестирования пользователю: ";
$TLS_title_assign_users = "Назначить пользователей на план тестирования: ";
</code-php>

==lib/plan/planTestersNavigator.php==
<code-php>
$TLS_nav_test_plan = "Навигатор - Планы тестирования";
$TLS_nav_users = "Навигатор - Пользователи";
</code-php>

==lib/plan/planUpdateTC.php==
<code-php>
$TLS_category_has_changed = "Группа тестов изменена";
$TLS_component_has_changed = "Группа тестов изменена";
$TLS_deleted = "удалена";
$TLS_different_versions = "Различные версии";
$TLS_plan_update_no_tc_updated = "Ни один тест не изменен";
$TLS_planupdate_tc_deleted1 = "Тест";
$TLS_planupdate_tc_deleted2 = "был удален.";
$TLS_planupdate_tc_updated1 = "Тест";
$TLS_planupdate_tc_updated2 = "был изменен.";
$TLS_tcorder_has_changed = "Порядок тестов был изменен";
$TLS_updated = "изменен";
</code-php>

==lib/plan/testSetNavigator.php==
<code-php>
$TLS_title_test_plan_navigator = "Навигация по планам тестирования";
</code-php>

==lib/plan/testSetRemove.php==
<code-php>
$TLS_tcase_removed_from_tplan="тест удален из плана тестирования";
$TLS_multiple_tcase_removed_from_tplan="Тесты удалены из плана тестирования";
</code-php>

==lib/plan/planEdit.php==
<code-php>
$TLS_testplan_created_ok = "План тестирования был создан";
$TLS_update_tp_failed1 = "Правка плана тестирования '";
$TLS_update_tp_failed2 = "' не удалась";
$TLS_warning_duplicate_tplan_name = "План тестирования с таким именем уже есть. Выберите другое имя!";
</code-php>

==lib/print/selectData.php==
<code-php>
$TLS_opt_show_doc_header = "Показать заголовок документа";
$TLS_opt_show_tc_body = "Показать тело теста";
$TLS_opt_show_tc_summary = "Показать резюме теста";
$TLS_opt_show_toc = "Показать Содержание";
$TLS_opt_show_tc_author = "Показать автора теста";
$TLS_opt_show_passfail = "Показать статус «пройден/провален» и заметки";
$TLS_title_tc_print_navigator = "Навигация - Печать спецификации тестов";
$TLS_title_tp_print_navigator = "Навигация - Печать плана тестирования";
</code-php>

==lib/project/projectedit.php==
<code-php>
$TLS_error_product_name_duplicate = "Уже есть проект с именем %s. <br>Пожалуйста, выберите другое имя";
$TLS_info_no_more_prods = "проектов больше нет.";
$TLS_info_product_activated = "проект активирован.";
$TLS_info_product_inactivated = "проект деактивирован.";
$TLS_info_product_not_deleted_check_log = "Не удалось удалить проект. Проверьте лог TestLink'а.";
$TLS_info_product_was_deleted = "проект успешно удален.";
$TLS_refer_to_log = " Пожалуйста, изучите лог TestLink'а для дополнительной информации.";
$TLS_test_project_activated = "проект %s успешно активирован";
$TLS_test_project_created = "проект %s успешно создан";
$TLS_test_project_deleted = "проект %s успешно удален";
$TLS_test_project_inactivated = "проект %s успешно деактивирован";
$TLS_test_project_updated = "проект %s успешно отредактирован";
$TLS_test_project_update_failed = "Правка проекта %s не удалась!";
</code-php>

==lib/results/charts.php==
<code-php>
$TLS_maani_copyright = "flash technology предоставлена http://www.maani.us";
$TLS_graphical_reports = "Графические отчеты";
$TLS_overall_metrics = "Общие метрики";
$TLS_results_by_keyword = "Результаты по ключевому слову";
$TLS_results_by_tester = "Рузультаты по тестировщику";
$TLS_results_top_level_suites = "Результаты по топ группам тестов";
</code-php>

==lib/req/reqImport.php==
<code-php>
$TLS_file_is_not_ok_for_import_type = "Кажется тип файла не совпадает с выбранным для импорта типом";
$TLS_file_is_not_text = "Это не текстовый файл. Использовать нельзя.";
$TLS_please_choose_req_file = "Пожалуйста, выберите файл для загрузки";
$TLS_req_import_finished = "Импорт завершен!";
</code-php>

==lib/req/reqSpecView.php==
<code-php>
$TLS_cant_create_tc_from_req_nothing_sel = "Пожалуйста, выберите требование!";
$TLS_req_created = "Требование %s успешно создано.";
</code-php>

==lib/req/reqTcAssign.php==
<code-php>
$TLS_req_msg_noselect = "Ничего не выбрано";
$TLS_req_msg_notupdated_coverage = "Покрытие не обновлено для Требований: ";
</code-php>

==lib/results/resultsBugs.php==
<code-php>
$TLS_title_test_report_all_builds = "Отчет: Результаты тестов для всех сборок";
</code-php>

==lib/results/resultsAllBuilds.php==
<code-php>
$TLS_title_metrics_x_build = " - Результаты тестов. Метрики X Сборки";
</code-php>

==lib/results/resultsByStatus.php==
<code-php>
$TLS_list_of_blocked = "Список блокированных тестов";
$TLS_list_of_failed = "Список проваленных тестов";
$TLS_list_of_not_run = "Список незапущенных тестов";
</code-php>

==lib/results/resultsTC.php==

==lib/results/resultsNavigator.php==
<code-php>
$TLS_link_charts="Диаграммы";
$TLS_link_report_blocked_tcs = "Блокированные тесты";
$TLS_link_report_failed = "Проваленные тесты";
$TLS_link_report_general_tp_metrics = "Общие метрики плана тестирования";
$TLS_link_report_metrics_active_build = "Метрики активной сборки";
$TLS_link_report_metrics_more_builds = "Запрос метрик";
$TLS_link_report_not_run="Не запущенные тесты";
$TLS_link_report_overall_build = "Общий статус всех сборок";
$TLS_link_report_reqs_coverage = "Отчет о выполнении требований";
$TLS_link_report_test = "Отчет о прогоне тестов";
$TLS_link_report_total_bugs = "Всего багов по каждому тесту";
</code-php>

==lib/results/resultsSend.php==
<code-php>
$TLS_send_to_empty_email_warning = "Пожалуйста, введите правильный email.";
$TLS_warning_create_build_first = "Сначала Вы должны создать или импортировать сборки.";
</code-php>

==lib/results/displayMgr.php==
<code-php>
$TLS_error_sendreport_no_email_credentials = "Email для этого пользователя не указан, пожалуйста, укажите его в настройках своего профиля";
</code-php>

==lib/testcases/archive.inc.php==

==lib/testcases/listTestCases.php==

==lib/testcases/tcImport.php==
<code-php>
$TLS_please_choose_file_to_import = "Пожалуйста, выберите файл для импорта";
$TLS_title_tc_import_to = "Импорт тестов";
$TLS_title_tsuite_import_to = "Импорт группы тестов";
$TLS_wrong_xml_tcase_file = "Некорректный XML в файле с тестами";
$TLS_wrong_xml_tsuite_file = "Некорректный XML в файле с группой тестов";
</code-php>

==lib/testcases/tcexport.php==
<code-php>
$TLS_no_testcases_to_export = "Нет тестов для экспорта";
$TLS_no_testsuites_to_export = "Нет группы тестов для экспорта";
$TLS_title_tc_export = "Экспорт теста";
$TLS_title_tc_export_all = "Экспортировать все тесты";
$TLS_title_tsuite_export = "Экспортировать все группы тестов";
$TLS_title_tsuite_export_all = "Экспортировать все группы тестов";
</code-php>

==lib/testcases/containerEdit.php==
<code-php>
$TLS_delete = "Удалить";
$TLS_delete_notice = "Внимание: Все связанные результаты прогонов будут удалены";
$TLS_warning_empty_com_name = "Пожалуйста, задайте имя для группы тестов";
</code-php>

==lib/testcases/tcEdit.php==
<code-php>
$TLS_current = "текущий";
$TLS_delete_linked = "Ссылки на планы тестирования будут удалены.";
$TLS_delete_linked_and_exec = "Ссылки на планы тестирования и результаты выполнения будут удалены.";
$TLS_error_tc_add = "При добавлении теста произошла ошибка";
$TLS_title_del_tc = "Удалить тест ";
</code-php>

==lib/usermanagement/rolesview.php==
<code-php>
$TLS_error_role_deletion = "Не удалось удалить роль!";
</code-php>

==lib/usermanagement/usersassign.php==
<code-php>
$TLS_no_test_projects = "Не заведено ни одного проекта";
$TLS_no_test_plans = "Для этого проекта не заведено ни одного плана тестирования";
$TLS_test_project_user_roles_updated = "Пользовательские роли обновлены";
$TLS_test_plan_user_roles_updated = "Пользовательские роли обновлены";
</code-php>

==lib/usermanagement/usersedit.php==
<code-php>
$TLS_user_created="Пользователь %s был успешно создан";
$TLS_user_deleted="Пользователь %s был успешно удален";
$TLS_user_not_added = "Не удалось добавить пользователя!";
</code-php>

==lib/usermanagement/rolesedit.php==
<code-php>
$TLS_error_role_creation = "Не удалось создать роль!";
$TLS_error_role_update = "Не удалось исправить роль!";
</code-php>

==lib/cfields/cfields_edit.php==
<code-php>
$TLS_cf_name_exists = "Пользовательское поле с таким именем уже существует. Пожалуста, выберите другое имя.";
$TLS_error_creating_cf = "Не удалось создать пользовательское поле!";
$TLS_do_update = "исправлено";
$TLS_do_delete = "удалено";
$TLS_do_add = "добавлено";
</code-php>

==resultsBugs.tpl==
<code-php>
$TLS_Open="Открыто";
$TLS_Resolved="Исправленных";
$TLS_Total="Всего";
$TLS_TCs_with_Bugs="Тестов с багами";
</code-php>

Strings.txt (TestLink-RU)

2007-10-07T13:15:00Z

Andrew: /* lib/results/resultsNavigator.php */

[[Category:TestLink]]

Статьяz с основной локализацией интерфейса. Статья разбита по разделам, в соответствии с разделами в оригинальном файле <tt>strings.txt</tt>. По ссылке «[[#Скачать|скачать]]» можно получить готовый PHP-файл, который нужно разместить в каталоге
testlink\locale\ru_RU\strings.txt

=Скачать=
[{{SERVER}}{{localurl:Special:CisGetPHPPage|pagetitle={{PAGENAMEE}}}} Получить PHP-код]

= Оригинал (наиболее полный английский перевод) =
* http://testlink.cvs.sourceforge.net/testlink/testlink/locale/en_GB/

=Разделы файла strings.txt (ru_RU)=
<code-php>
/**
* TestLink Open Source Project - http://testlink.sourceforge.net/
*
* Filename $RCSfile: strings.txt,v $
*
* @version $Revision$
* @modified $Date$ $Author$
*
* @author Vadim Ivanchenko, Stas Fomin, and russian Testlink community.
* http://lib.custis.ru/index.php/TestLink:_strings.txt_%28RU%29
*
*
**/

$TLS_STRINGFILE_CHARSET = "UTF-8";
</code-php>

==General==
<code-php>
$TLS_asc = "по возрастанию";
$TLS_btn_no = "Нет";
$TLS_create = "Создать";
$TLS_desc = "по убыванию";
$TLS_test_case = "Тест";
$TLS_testcase = $TLS_test_case;
$TLS_test_plan = "План тестирования";
$TLS_testplan = $TLS_test_plan;
$TLS_test_suite = "Группа тестов";
$TLS_SRS = "SRS";
$TLS_Role = "Роль";
$TLS_Keyword = "Ключевое слово";
$TLS_Milestone = "Веха";
$TLS_testsuite_created = "Группа тестов создана";
$TLS_requirement = "Требование";
$TLS_assigned = "назначен";
$TLS_unassigned = "свободен";
$TLS_import_file_type = "Тип импортируемого файла";
$TLS_max_file_size_is = "Макс. размер файла";
$TLS_supported_file_formats = "Поддерживаемые форматы файлов";
</code-php>

==firstLogin.php==
<code-php>
$TLS_cant_create_user = "К сожалению, не удалось создать ваш логин. Пожалуйста, свяжитесь с администратором!";
$TLS_empty_email_address = " Пожалуйста, укажите e-mail!";
$TLS_empty_first_name = " Пожалуйста, укажите имя пользователя.";
$TLS_empty_last_name = " Пожалуйста, укажите фамилию.";
$TLS_fatal_page_title = "TestLink ::: Fatal Error";
$TLS_invalid_user_name = "Некорректный логин пользователя. Пожалуйста, придумайте другой.";
$TLS_passwd_dont_match = "Два введенных пароля не совпадают. Учтите, что пароли чувствительны к регистру, и попробуйте ещё раз.";
$TLS_user_cant_be_created_because = "Не удалось создать ваш аккаунт. Причина:";
$TLS_user_name_exists = "Этот логин пользователя уже используется. Пожалуйста, выберите другой.";
$TLS_valid_user_name_format = "Логин пользователя может состоять только из алфавитно-цифровых символов, пробелов, дефисов и подчеркиваний.";
$TLS_warning_empty_pwd = "Пожалуйста, укажите пароль. Пароль не может быть пустым.";
$TLS_your_info_please = "Введите информацию о пользователе";
</code-php>

==index.php==
<code-php>
$TLS_main_page_title = "TestLink::Главная страница";
</code-php>

==keywordsimport.php==
<code-php>
$TLS_please_choose_keywords_file = "Пожалуйста, выберите файл для загрузки";
$TLS_keywords_file = "Файл с ключевыми словами";
</code-php>

==lostPassword.php==
<code-php>
$TLS_bad_user = "Пользователь не найден, попробуйте еще";
$TLS_contact_admin = "<br> Если проблемы будут продолжаться, пожалуйста, свяжитесь с администратором системы.";
$TLS_mail_empty_address = "Вы не указали email-адреса в вашем профиле! Теперь, чтобы сбросить пароль вам нужно связаться с администратором TestLink-системы.";
$TLS_mail_passwd_subject = "Ваш новый пароль к TestLink'у.";
$TLS_mail_problems = "Ошибка в почтовых настройках, пожалуйста, свяжитесь с администратором.";
$TLS_page_title_lost_passwd = "TestLink - Утерян пароль";
$TLS_your_info_for_passwd = "Заполните информацию о вашем пользователе, и пароль будет вам выслан по почте.";
$TLS_your_password_is = "Ваш пароль к TestLink'у: <br>";
</code-php>

==login.php==
<code-php>
$TLS_bad_user_passwd = "Логин или пароль неверен. Попробуйте ещё!";
$TLS_login_msg_session_exists1 = "Ваша сессия в этом броузере ещё активна. Пожалуйста, используйте ";
$TLS_login_msg_session_exists2 = " если вы хотите обновить вашу сессию.";
$TLS_logout_link = "Выход";
$TLS_passwd_lost = "Ваш пароль выслан вам по email на адрес, который вы указали при регистрации. Проверьте вашу почту. В случае проблем, обратитесь к администратору вашего TestLink'а.";
$TLS_password_reseted="Новый пароль выслан вам по почте";
$TLS_please_login = "Пожалуйста, войдите в систему...";
$TLS_session_expired = "Время ваша сессии окончилось. Пожалуйста, войдите в систему заново.";
$TLS_your_first_login = "Добро пожаловать в TestLink! Сейчас у вас только гостевой доступ. Для большего, нужно войти в систему.";
</code-php>

==planPriority.php==
<code-php>
$TLS_high_priority = "Высокий";
$TLS_low_priority = "Низкий";
$TLS_medium_priority = "Средний";

$TLS_high_risk = "Высокий";
$TLS_low_risk = "Низкий";
$TLS_medium_risk = "Средний";

$TLS_high_importance = "Высокая";
$TLS_low_importance = "Низкая";
$TLS_medium_importance= "Средняя";
</code-php>

==tcEdit.php==
<code-php>
$TLS_tc_created = "Тест %s успешно создан";
$TLS_tc_deleted = "Тест %s успешно удален";
$TLS_tc_updated = "Тест %s отредактирован успешно";
$TLS_tc_update_failed = "Не удалась правка теста %s!";
</code-php>

==gui/templates/attachment404.tpl==
<code-php>
$TLS_btn_close = "Закрыть";
$TLS_error_attachment_not_found = "Ошибка: Вложение не найдено!";
$TLS_title_downloading_attachment = "Загружаем вложение";
</code-php>

==gui/templates/attachmentdelete.tpl==
<code-php>
$TLS_deleting_was_ok = "Вложение удалено.";
$TLS_error_attachment_delete = "При удалении вложения произошла ошибка!";
$TLS_title_delete_attachment = "Удалить вложение";
</code-php>

==gui/templates/containerDelete.tpl==
<code-php>
$TLS_btn_yes_del_comp = "Да, удалить группу тестов";
$TLS_container_title_testsuite =$TLS_test_suite;
$TLS_linked_but_not_executed="Связан с одним или более планом тестирования, но не выполнялась";
$TLS_question_del = "Действительно удалить";
$TLS_th_link_exec_status = "Статус исполнения и связей";
</code-php>

==gui/templates/containerNew.tpl==
<code-php>
$TLS_btn_create_testsuite = "Создать группу тестов";
$TLS_tc_keywords = "Ключевые слова";
$TLS_title_create = "Создать";
$TLS_warning_empty_testsuite_name = "Пожалуйста, задайте имя для группы тестов";
</code-php>

==gui/templates/bug_add.tpl==
<code-php>
$TLS_btn_add_bug = "Добавить баг";
$TLS_bug_id = "Bug id";
$TLS_button_enter_bug = "Создать новый баг";
$TLS_title_bug_add = "Добавить баг";
$TLS_link_bts_create_bug = "Доступ к системе регистрации багов";
</code-php>

==gui/templates/bug_delete.tpl==
<code-php>
$TLS_title_delete_bug = "Удалить баг";
</code-php>

==gui/templates/containerMove.tpl==
<code-php>
$TLS_btn_cp = "Копировать";
$TLS_btn_move = "Переместить";
$TLS_choose_target = "Выберите куда";
$TLS_cont_move_first = "Переместить это";
$TLS_cont_move_second = "в другое";
$TLS_copy_keywords = "Копировать ключевые слова";
$TLS_defined_exclam = "определен !";
$TLS_include_nested = "Включая вложенные данные (только для копирования).";
$TLS_sorry_further = "К сожалению, больше ничего нет ";
$TLS_title_move_cp = "Переместить/Скопировать";
</code-php>

==gui/templates/reqCreate.tpl==
<code-php>
$TLS_btn_cancel = "Отменить";
$TLS_btn_create = "Создать";
$TLS_help = "Помощь";
$TLS_req_create = "Создать требование";
$TLS_req_doc_id = "DOC-ID";
$TLS_req_spec = "Спецификация требований";
$TLS_reqs = "Требования";
$TLS_scope = "Описание";
$TLS_status = "Состояние";
$TLS_title = "Заголовок";
$TLS_warning_empty_req_title = "Заголовок требования должен быть не пуст!";
$TLS_warning_empty_reqdoc_id = "ID документа-требования не должен быть пуст!";
</code-php>

==gui/templates/containerOrder.tpl==
<code-php>
$TLS_btn_upd = "Обновить";
$TLS_no_nodes_to_reorder = "К сожалению, тут нечего упорядочивать.";
$TLS_node = "Имя";
$TLS_th_id = "ID";
$TLS_th_node_type = "Тест / Группа тестов";
$TLS_th_order = "Порядок";
$TLS_title_change_node_order = "Изменить порядок 'потомков'";
$TLS_node_type_dbtable_testsuites=$TLS_test_suite;
$TLS_node_type_dbtable_testcases=$TLS_testcase;
</code-php>

==gui/templates/containerView.tpl==
<code-php>
$TLS_alt_del_com = "Удалить эту группу тестов";
$TLS_alt_edit_com = "Править дату и заголовок для этой группы тестов";
$TLS_alt_move_cp_com = "Переместить или скопировать эту группу тестов в другой проект";
$TLS_btn_del_com = "Удалить";
$TLS_btn_edit_com = "Править";
$TLS_btn_export_all_testsuites = "Экспортировать все группы тестов";
$TLS_btn_export_tc = "Экспортировать тест(ы)";
$TLS_btn_export_testsuite = "Экспортировать группу тестов";
$TLS_btn_import_tc = "Импортировать тест(ы)";
$TLS_btn_import_testsuite = "Импортировать группу тестов";
$TLS_btn_move_cp_com = "Переместить/Копировать";
$TLS_btn_new_cat = "Новая группа тестов";
$TLS_btn_new_com = "Новая группа тестов";
$TLS_btn_new_tc = "Создать тест(ы)";
$TLS_btn_reorder_cat = "Переупорядочить потомков";
$TLS_edit_testproject_basic_data = "Править основные данные проекта";
$TLS_th_notes = "Описание";
$TLS_th_product_name = "Имя проекта";
</code-php>

==gui/templates/cfields_edit.tpl==
<code-php>
$TLS_available_on = "Доступно для";
$TLS_btn_add = "Добавить";
$TLS_btn_delete = "Удалить";
$TLS_btn_ok = "Ok";
$TLS_custom_field = "Пользовательское поле";
$TLS_enable_on_design = "Разрешить при <br>спецификации теста";
$TLS_enable_on_exec = "Разрешить при <br>прогоне теста";
$TLS_label = "Метка";
$TLS_name = "Имя";
$TLS_popup_delete_custom_field = "Вы уверены, что хотите удалить пользовательское поле?";
$TLS_possible_values = "Возможные значения";
$TLS_show_on_design = "Показывать при <br>спецификации теста";
$TLS_show_on_exec = "Показывать при <br>прогоне теста";
$TLS_testcase = $TLS_test_case;
$TLS_title_cfields_mgmt = "Пользовательские поля";
$TLS_type = "Тип";
$TLS_warning_empty_cfield_label = "Пожалуйста, введите метку для этого пользовательского поля.";
$TLS_warning_empty_cfield_name = "Пожалуйста, введите имя этого пользовательского поля.";
</code-php>

==gui/templates/inc_update.tpl==
<code-php>
$TLS_info_failed_db_upd = "Не удалось обновить базу данных!";
$TLS_info_failed_db_upd_details = "Не удалось обновить базу данных! - Подробности:";
$TLS_invalid_query = "Ошибка:";
$TLS_warning = "Предупреждение!!";
$TLS_was_success = " был(и) успешно ";
</code-php>

==gui/templates/execNavigator.tpl==
<code-php>
$TLS_TestPlan = "План тестирования";
$TLS_btn_apply_filter = "Применить фильтр";
$TLS_btn_update_menu = "Обновить меню";
$TLS_caption_nav_filter_settings = "Параметры выборки";
$TLS_current_build = "Текущая сборка";
$TLS_filter_owner = "Ответственный";
$TLS_filter_result = "Результат";
$TLS_filter_tcID = "Фильтр: ID теста";
$TLS_keyword = "Ключевое слово";
$TLS_test_status_all_status="Все";
</code-php>

==gui/templates/mainPage.tpl==
<code-php>
$TLS_th_my_perc_completed = "У меня выполнено [%]";
$TLS_th_name = "Имя";
$TLS_th_perc_completed = "Выполнено [%]";
$TLS_title_your_tp_metrics = "Ваши метрики для плана тестирования";
</code-php>

==gui/templates/newest_tcversions.tpl==
<code-php>
$TLS_linked_version = "Связанная версия";
$TLS_newest_version = "Самая новая из доступных активных версий";
$TLS_title_newest_tcversions = "Самые новые версии связанных тестов";
</code-php>

==gui/templates/emailSent.tpl==
<code-php>
$TLS_send_test_report = "- Послать тест-отчёт";
</code-php>

==gui/templates/reqImport.tpl==
<code-php>
$TLS_Result = "Результат";
$TLS_Title = "Заголовок";
$TLS_btn_back2srs = "Назад, к спецификации требований";
$TLS_btn_import = "Импорт";
$TLS_btn_upload_file = "Загрузить файл";
$TLS_check_req_file_structure = "Пожалуйста, проверьте формат файла. Не получается получить из этого файла требования";
$TLS_local_file = "Файл:";
$TLS_max_size_cvs_file1 = "Максимальный размер для этого файла";
$TLS_max_size_cvs_file2 = "kB";
$TLS_req_import_check_note = "Пожалуйста, разрешите возможные конфликты и запустите процесс импорта.";
$TLS_req_import_dont_empty = "Не импортируйте элементы с пустой Сферой";
$TLS_req_import_option_double = "Добавить ещё с тем же заголовком";
$TLS_req_import_option_header = "Разрешить конфликт";
$TLS_req_import_option_overwrite = "Обновить существующий";
$TLS_req_import_option_skip = "Пропускать импорт дублирующих требований";
$TLS_req_import_type = "Тип:";
$TLS_req_msg_norequirement = "Нет требований";
$TLS_required_cvs_format = "Формат файла с требованиями:";
$TLS_title_choose_file_type = "Выберите тип файла";
$TLS_title_choose_local_file = "Выберите файл для загрузки";
$TLS_title_req_import = "Загрузка требований";
$TLS_title_req_import_check_input = "Проверьте импортируемые данные";
</code-php>

==gui/templates/inc_attachments.tpl==
<code-php>
$TLS_alt_delete_build = "Удалить эту сборку";
$TLS_alt_delete_attachment = "Удалить это вложение";
$TLS_attached_files = "Вложенные файлы";
$TLS_attachment_feature_disabled = "вложения отключены";
$TLS_button_upload = "Загрузить";
$TLS_upload_file_new_file = "Загрузить новый файл";
$TLS_warning_delete_attachment = "Действительно удалить вложение?";
</code-php>

==gui/templates/resultsNavigator.tpl==
<code-php>
$TLS_btn_print = "Печать";
$TLS_note_email_sent_t = "Примечание: email format послан на email пользователя";
$TLS_send_results = "Послать отчеты";
$TLS_send_to = "To:";
$TLS_subject = "Subject:";
$TLS_title_active_build = "Активная сборка";
$TLS_title_report_type = "Формат отчета";
$TLS_via_email = "через eMail";
</code-php>

==gui/templates/inc_attachments_upload.tpl==

==gui/templates/cfields_view.tpl==
<code-php>
$TLS_btn_cfields_create = "Создать";
$TLS_manage_cfield = "Управлять пользовательскими полями";
</code-php>

==gui/templates/inc_cat_viewer_ro_m0.tpl==
<code-php>
$TLS_cat_scope = "Описание";
$TLS_category = "Группа тестов";
$TLS_configuration = "Конфигурация";
$TLS_data = "Данные";
$TLS_not_defined = "Не определено.";
$TLS_tools = "Инструменты";
</code-php>

==gui/templates/inc_cat_viewer_rw.tpl==
<code-php>
$TLS_cat_alt_name = "Обязательно заполнить имя группы тестов.";
$TLS_cat_config = "Конфигурация";
$TLS_cat_data = "Данные";
$TLS_cat_name = "Имя группы тестов";
$TLS_cat_tools = "Инструменты";
</code-php>

==gui/templates/reqEdit.tpl==
<code-php>
$TLS_btn_update = "Обновить";
$TLS_by = "by";
$TLS_coverage = "Покрытие";
$TLS_popup_delete_req = "Удалить это требование, Вы уверены?";
$TLS_req_edit = "Править требование";
$TLS_req_msg_notestcase = "Связанных тестов нет.";
$TLS_requirement_spec = "Спецификация требования";
$TLS_test_case_id = "ID";
$TLS_title_created = "Создано:";
$TLS_title_last_mod = "Последняя правка:";
</code-php>

==gui/templates/buildNew.tpl==
<code-php>
$TLS_active = "Активная";
$TLS_enter_build = "Заголовок";
$TLS_enter_build_notes = "Описание";
$TLS_msg_build = "Замечание: Каждая сборка относится к активному плану тестирования. Описание должно включать: список развертываемых пакетов, утверждений, состояние, и т.п.";
$TLS_open = "Открыть";
$TLS_test_plan = "План тестирования";
$TLS_title_build_2 = "Управление сборками";
$TLS_title_build_create = "Создать новую Сборку";
$TLS_title_build_update = "Править Сборку";
$TLS_warning_empty_build_name = "Пожалуйста, введите имя для этой Сборки!";
</code-php>

==gui/templates/inc_comp_viewer_ro.tpl==
<code-php>
$TLS_component = "Группа тестов";
$TLS_introduction = "Введение";
$TLS_limitations = "Ограничения";
$TLS_methodology = "Методология";
$TLS_references = "Ссылки";
</code-php>

==gui/templates/inc_comp_viewer_rw.tpl==
<code-php>
$TLS_comp_alt_name = "Обязательно введите имя группы тестов.";
$TLS_comp_intro = "Введение";
$TLS_comp_lim = "Ограничения";
$TLS_comp_method = "Методология";
$TLS_comp_name = "Имя группы тестов";
$TLS_comp_ref = "Ссылки";
$TLS_comp_scope = "Описание";
</code-php>

==gui/templates/reqSpecView.tpl==
<code-php>
$TLS_btn_analyse = "Анализировать";
$TLS_btn_check_all = "Проверить все";
$TLS_btn_delete_spec = "Удалить спецификацию";
$TLS_btn_edit_spec = "Править спецификацию";
$TLS_btn_export_reqs = "Экспортировать требования";
$TLS_btn_req_create = "Создать новое требование";
$TLS_btn_spec_list = "Список спецификаций";
$TLS_btn_uncheck_all = "Убрать все отметки";
$TLS_cant_delete_req_nothing_sel = "Пожалуйста, выберите требование!";
$TLS_popup_sure_delete = "Вы уверены удалить эту спецификацию требования?";
$TLS_req_select_create_tc = "Создать тесты";
$TLS_req_select_delete = "Удалить требования";
$TLS_req_title_list = "Список требований";
$TLS_req_total = "Всего треб.";
$TLS_req_reorder = "Переупорядочить требования?";
$TLS_warning_delete_requirements = "Вы уверены удалить выбранные требования?";
$TLS_title_change_req_order = "Переупорядочивание требований";
</code-php>

==gui/templates/inc_copyrightnotice.tpl==
<code-php>
$TLS_gnu_gpl = "GNU GPL";
$TLS_lic_home = "Домой";
$TLS_lic_product = "TestLink project";
$TLS_licensed_under = "TestLink лицензируется согласно ";
</code-php>

==gui/templates/containerEdit.tpl==
<code-php>
$TLS_btn_update_testsuite = "Обновить группу тестов";
$TLS_title_edit_level = "Править";
</code-php>

==gui/templates/reqSpecAnalyse.tpl==
<code-php>
$TLS_edit = "Править";
$TLS_none = "Пусто ";
$TLS_req = "Требования";
$TLS_req_spec_change = "Изменить спецификацию требований на ";
$TLS_req_title_analyse = "Анализировать спецификацию требований ";
$TLS_req_title_covered = "Покрытые требования";
$TLS_req_title_in_tl = "Требований, зарегистрированных в TestLink";
$TLS_req_title_nottestable = "Нетестируемые требования";
$TLS_req_title_uncovered = "Непокрытые требования";
$TLS_req_title_not_in_tl = "Требований, отсутствующих в TestLink";
$TLS_req_total_count = "Всего требований";
$TLS_testcases = "Тесты";
</code-php>

==gui/templates/reqSpecCreate.tpl==
<code-php>
$TLS_action_create_srs = "Создать спецификацию требований";
$TLS_testproject = "проект";
</code-php>

==gui/templates/inc_reqView.tpl==
<code-php>
$TLS_Author = "Автор";
$TLS_last_edit = "Последняя правка: ";
</code-php>

==gui/templates/inc_res_by_comp.tpl==
<code-php>
$TLS_title_res_by_top_level_suites = "Результаты топовых групп тестов";
$TLS_trep_blocked = "Блокировано";
$TLS_trep_comp = "Группа тестов";
$TLS_trep_comp_perc = "Выполнена [%]";
$TLS_trep_failed = "Сбой";
$TLS_trep_not_run = "Не запускали";
$TLS_trep_passed = "Выполнено";
$TLS_trep_total = "Всего";
</code-php>

==gui/templates/inc_res_by_keyw.tpl==
<code-php>
$TLS_title_res_by_kw = "Результаты по ключевому слову";
$TLS_trep_kw = "Ключевое слово";
</code-php>

==gui/templates/inc_res_by_owner.tpl==
<code-php>
$TLS_title_res_by_owner = "Результаты по тестировщику";
$TLS_trep_owner = "Тестировщик";
$TLS_title_res_by_tester = "Результаты по тестировщику";
$TLS_trep_tester = "Тестировщик";
</code-php>

==gui/templates/inc_res_by_prio.tpl==
<code-php>
$TLS_tit_end_date = "Дата окончания";
$TLS_tit_milestone = "Веха";
$TLS_title_res_by_prio = "Результаты по приоритету";
$TLS_trep_milestone_goal = "Цель вехи [%]";
$TLS_trep_prio = "Приоритет";
$TLS_trep_status = "Состояние";
</code-php>

==gui/templates/inc_res_by_ts.tpl==
<code-php>
$TLS_title_res_by_ts = "Результаты по группе тестов";
$TLS_trep_imp = "Важность";
$TLS_trep_risk = "Риск";
$TLS_trep_ts = "Группа тестов";
</code-php>

==gui/templates/reqSpecEdit.tpl==

==gui/templates/inc_show_bug_table.tpl==
<code-php>
$TLS_build = "Сборка";
$TLS_caption_bugtable = "Связанные баги";
$TLS_delete_bug="Удалить баг";
$TLS_del_bug_warning_msg = "Действительно удалить этот баг?";
</code-php>

==gui/templates/reqSpecList.tpl==
<code-php>
$TLS_btn_assign_tc = "Указать тест";
$TLS_no_docs = "Нет доступных документов.";
$TLS_req_list_docs = "Спецификации требований";
</code-php>

==gui/templates/tcEdit_New_viewer.tpl==
<code-php>
$TLS_alt_add_tc_name = "Обязательно укажите имя теста.";
$TLS_expected_results = "Ожидаемые результаты";
$TLS_steps = "Шаги";
$TLS_summary = "Резюме";
$TLS_tc_title = "Заголовок тест-кейса";
</code-php>

==gui/templates/show_exec_notes.tpl==
<code-php>
$TLS_title_execution_notes = "Замечания по выполнению";
</code-php>

==gui/templates/rolesedit.tpl==
<code-php>
$TLS_btn_create_role = "Создать";
$TLS_btn_edit_role = "Править";
$TLS_caption_define_role = "Определить роль";
$TLS_caption_possible_affected_users = "Возможно влияет на следующих пользователей";
$TLS_enter_role_notes = "Введите описание роли";
$TLS_menu_assign_product_roles = "Укажите роли проекта";
$TLS_menu_assign_testplan_roles = "Укажите роли для плана тестирования";
$TLS_menu_define_roles = "Новая роль";
$TLS_menu_mod_user = "Править пользователя";
$TLS_menu_new_user = "Новый пользователь";
$TLS_menu_edit_user = "Редактировать пользователя";
$TLS_menu_view_users = "Список пользователей";
$TLS_menu_view_roles = "Просмотр ролей";
$TLS_th_cf_rights = "Права на пользовательские поля";
$TLS_th_kw_rights = "Права на ключевые слова";
$TLS_th_mgttc_rights = "Права на управление тест-кейсами";
$TLS_th_product_rights = "Права на проект";
$TLS_th_req_rights = "Права на требование";
$TLS_th_rights = "Разрешения";
$TLS_th_rolename = "Роль";
$TLS_th_tp_rights = "Права на план тестирования";
$TLS_th_user_rights = "Права пользователей";
$TLS_title_user_mgmt = "Управление пользователями";
$TLS_warning_modify_role = "Действительно исправить роль?";
</code-php>

==gui/templates/tcSearchForm.tpl==
<code-php>
$TLS_btn_find = "Найти";
$TLS_caption_search_form = "Искать тесты";
$TLS_not_applied = "Не применимо";
$TLS_th_tcid = "ID теста";
$TLS_th_tcversion = "Версия";
$TLS_th_title = "Заголовок";
$TLS_title_search_tcs = "Поиск";
</code-php>

==gui/templates/infoWindow.tpl==

==gui/templates/tcDelete.tpl==
<code-php>
$TLS_btn_yes_iw2del = "Да, удалите тест!";
$TLS_question_del_tc = "Действительно удалить тест?";
$TLS_th_executed = "Выполнено";
$TLS_th_linked_to_tplan = "Связан с планом тестирования";
$TLS_th_version = "Версия";
</code-php>

==gui/templates/tcNew.tpl==
<code-php>
$TLS_title_new_tc = "Создать тест";
$TLS_warning_empty_tc_title = "Пожалуйста, задайте заголовок для теста";
</code-php>

==gui/templates/tcImport.tpl==
<code-php>
$TLS_title_imp_tc_data = "Импорт данных для теста";
</code-php>

==gui/templates/keywordsimport.tpl==
<code-php>
$TLS_title_keyword_import_to = "Импортировать ключевые слова в ";
$TLS_title_keyword_import = "Импорт ключевых слов";
</code-php>

==gui/templates/keywordsexport.tpl==
<code-php>
$TLS_btn_export = "Экспорт";
$TLS_title_req_import_to = "Импортировать требования в документ:";
</code-php>

==gui/templates/cfields_tproject_assign.tpl==
<code-php>
$TLS_btn_assign = "Привязать";
$TLS_btn_cfields_active_mgmt = "Обновить активное состояние";
$TLS_btn_cfields_display_order = "Сохранить порядок показа";
$TLS_btn_unassign = "Освободить от";
$TLS_cfields_active = "Активный";
$TLS_cfields_tproject_assign = "Привязать пользовательские поля";
$TLS_display_order = "Порядок показа";
$TLS_title_assigned_cfields = "Привязанные пользовательские поля";
$TLS_title_available_cfields = "Доступные пользовательские поля";
</code-php>

==gui/templates/usersview.tpl==
<code-php>
$TLS_No = "Нет";
$TLS_Yes = "Да";
$TLS_alt_delete_user = "Действительно удалить выбранного пользователя?";
$TLS_alt_edit_user = "Править пользователя";
$TLS_order_by_login = "По порядку логинов";
$TLS_order_by_role_descr = "По порядку описания ролей";
$TLS_th_active = "Активный";
$TLS_th_delete = "Удалить?";
$TLS_th_email = "Email";
$TLS_th_first_name = "Имя";
$TLS_th_last_name = "Фамилия";
$TLS_th_locale = "Локализация";
$TLS_th_login = "Логин";
$TLS_th_role = "Роль";
$TLS_warning_delete_user = "Действительно удалить выбранного пользователя?";
</code-php>

==gui/templates/login.tpl==
<code-php>
$TLS_btn_login = "Войти";
$TLS_login_name = "Логин:";
$TLS_lost_password_q = "Забыли пароль?";
$TLS_new_user_q = "Новый пользователь?";
$TLS_password = "Пароль:";
</code-php>

==gui/templates/loginFirst.tpl==
<code-php>
$TLS_btn_add_user_data = "Добавить пользовательские данные";
$TLS_e_mail = "E-mail (нужен, чтобы получить новый пароль):";
$TLS_first_name = "Имя:";
$TLS_last_name = "Фамилия:";
$TLS_link_back_to_login = "Войти еще раз";
$TLS_password_again = "Повторите пароль:";
$TLS_password_mgmt_is_external = "Используется внешнее управление паролями";
</code-php>

==gui/templates/tcMove.tpl==
<code-php>
$TLS_btn_mv = "Переместить";
$TLS_choose_cat = "Выберите группу тестов";
$TLS_inst_move = "Переместить этот тест в другую группу тестов (внутри того же плана тестирования).";
$TLS_title_mv_cp_tc = "Переместить/Копировать тест";
</code-php>

==gui/templates/loginLost.tpl==
<code-php>
$TLS_btn_send = "Выслать пароль";
$TLS_password_reset = "Сбросить пароль";
</code-php>

==gui/templates/tcView.tpl==
<code-php>
$TLS_no_records_found = "Ничего не найдено.";
</code-php>

==gui/templates/execSetResults.tpl==
<code-php>
$TLS_alt_attachment_mgmt = "вложения";
$TLS_alt_notes = "заметки";
$TLS_attachment_mgmt = "вложения";
$TLS_btn_history_off = "Показывать только последний прогон";
$TLS_btn_history_on = "Показывать полную историю прогонов";
$TLS_btn_save_all_tests_results = "Сохранить все результаты прогонов";
$TLS_btn_save_tc_exec_results = "Сохранить результат прогона";
$TLS_bug_mgmt = "Управление багами";
$TLS_build_is_closed = "Сборка закрыта";
$TLS_builds_notes = "Описание сборки";
$TLS_bulk_tc_status_management = "Массовое управление состоянием тестов";
$TLS_date_time_run = "Дата";
$TLS_details = "Подробности";
$TLS_exec_notes = "Заметки";
$TLS_exec_status = "Состояние";
$TLS_execution_history = "История прогонов";
$TLS_img_title_bug_mgmt = "Управление багами";
$TLS_img_title_delete_execution= "Удалить прогон";
$TLS_just_last_execution_for_this_build = "Последний прогон для этой сборки";
$TLS_no_data_available = "Данные отсутствуют";
$TLS_set_all_tc_to = "Установить всем состояние ";
$TLS_show_hide = "Показать / скрыть";
$TLS_tc_not_tested_yet = "Еще не протестировано:";
$TLS_test_cases_cannot_be_executed = "Тесты не могут быть выполнены";
$TLS_test_exec_by = "Протестировано: ";
$TLS_test_exec_expected_r = "Ожидаемые результаты";
$TLS_test_exec_last_run_date = "Самые последние запуски:";
$TLS_test_exec_notes = "Заметки / Описание";
$TLS_test_exec_on_build = " в Сборке";
$TLS_test_exec_result = "Результат";
$TLS_test_exec_steps = "Шаги";
$TLS_test_exec_summary = "Резюме";
$TLS_test_plan_notes = "Заметки по плану тестирования";
$TLS_test_status_not_run = "Не запущен";
$TLS_th_test_case_id = "ID ";
$TLS_th_testsuite = "Группа тестов";
$TLS_title_t_r_on_build = "Результы тестов по Сборке";
$TLS_title_t_r_owner = " Ответственный:";
$TLS_title_test_case = "Тест";
$TLS_version = "Версия";
</code-php>

==gui/templates/inc_testsuite_viewer_ro.tpl==
<code-php>
$TLS_keywords = "Ключевые слова";
$TLS_test_suite = "Группа тестов";
</code-php>

==gui/templates/navBar.tpl==
<code-php>
$TLS_home = "Домой";
$TLS_link_logout = "Выход";
$TLS_product = "Проект";
$TLS_product_role = "Роль проекта";
$TLS_title_edit_personal_data = "Мой профиль";
$TLS_title_execute = "Выполнить";
$TLS_title_results = "Отчеты";
$TLS_title_specification = "Спецификация";
</code-php>

==gui/templates/inc_testsuite_viewer_rw.tpl==

==gui/templates/planAddTC_m1.tpl==
<code-php>
$TLS_add_tc = "Добавить";
$TLS_add_remove_selected_tc_hint = "Операция будет выполнена над ВСЕМИ группами тестов";
$TLS_btn_add_remove_selected_tc = "Добавить / Удалить выбранное";
$TLS_btn_add_selected_tc = "Добавить выбранное";
$TLS_btn_check = "Отметить";
$TLS_btn_uncheck = "Снять отметки";
$TLS_check_uncheck_tc = "Все тесты в этой группе тестов.";
$TLS_check_uncheck_all_checkboxes="отметить все/снять все отметки";
$TLS_has_been_executed = "были выполнены";
$TLS_inactive_testcase = "неактивны";
$TLS_no_testcase_available = "Тестов нет";
$TLS_note_keyword_filter = "Тесты фильтруются по ключевому слову";
$TLS_remove_tc = "Удалить";
$TLS_th_test_case = "Тест";
$TLS_title_add_remove_test_to_plan = "Добавить/Удалить тест(ы) в/из плана тестирования";
$TLS_title_add_test_to_plan = "Добавить тесты в план тестирования";
$TLS_warning_add_remove_selected_tc = "Вы уверены удалить выбранные тесты из этого плана тестирования?";
</code-php>

==gui/templates/planAddTCNavigator.tpl==
<code-php>
$TLS_title_navigator = "Навигатор";
</code-php>

==gui/templates/planPriority.tpl==
<code-php>
$TLS_btn_upd_prio = "Сохранить";
$TLS_title_priority = "Определить приоритеты для плана тестирования";
$TLS_tr_th_importance = "Важность";
$TLS_tr_th_prio_cba = "Приоритет (C/B/A)";
$TLS_tr_th_risk = "Риск/Важность";
</code-php>

==gui/templates/planEdit.tpl==
<code-php>
$TLS_btn_testplan_create = "Создать";
$TLS_cancel = "Отменить";
$TLS_opt_no = "Нет";
$TLS_testplan_question_create_tp_from = "Создать из существующего плана тестирования?";
$TLS_testplan_th_active = "Активный";
$TLS_testplan_th_name = "Имя";
$TLS_testplan_th_notes = "Описание";
$TLS_testplan_title_create = "Создать новый план тестирования";
$TLS_testplan_title_edit = "Править план тестирования";
$TLS_testplan_title_for_project = "для проекта: ";
$TLS_testplan_title_tp_management = "Управление планами тестирования";
$TLS_testplan_txt_notes = <<<END
План тестирования должен содержать ясно определенные задачи, включая временные границы.
Он может содержать тест-активность для выпускаемой версии продукта (включая патчи)
или просто единственный запрос от пользователя.<br/>
В описании можно ссылаться на план и другую документацию по проекту.
Разумно перечислить тестируемые возможности, риски и т.п.<br/>
Можно создать новый план тестирования из существующего ("клонировать").
Будут скопированы следующие элементы: сборки, тесты, приоритеты,
Вехи и роли пользователей.<br/>
План тестирования можно деактивировать/заморозить: т.е. запретить любое изменение
атрибутов или вложенных элементов плана тестирования.
Такие планы тестирования будут видны только на странице отчетов и на этой странице.
END;

$TLS_warning_empty_tp_name = "Пожалуйста, введите имя плана тестирования.";
</code-php>

==gui/templates/planNew.tpl==
<code-php>
$TLS_testplan_btn_edit = "Сохранить";
$TLS_testplan_btn_new = "Создать";
$TLS_testplan_menu_create = "Создать";
$TLS_testplan_menu_edit = "Править";
$TLS_testplan_menu_list = "Список";
</code-php>

==gui/templates/planMilestones.tpl==
<code-php>
$TLS_alt_delete_milestone = "Удалить веху?";
$TLS_btn_edit_milestone = "Править";
$TLS_btn_new_milestone = "Создать";
$TLS_info_milestones_date = "Веха не может иметь дату раньше чем 'сегодня'";
$TLS_no_milestones = "Для этого плана тестирования вехи не определены.";
$TLS_popup_delete_milestones = "Вы уверены удалить веху %NAME% ?";
$TLS_warning_empty_milestone_name="Укажите имя вехи!";

$TLS_th_date_format = "Целевая Дата";
$TLS_th_perc_a_prio = "% A-приоритет";
$TLS_th_perc_b_prio = "% B-приоритет";
$TLS_th_perc_c_prio = "% C-приоритет";
$TLS_title_existing_milestones = "Существующие вехи";
$TLS_title_milestones = "Вехи для плана тестирования";
$TLS_title_new_milestone = "Новая Веха";
</code-php>

==gui/templates/projectedit.tpl==
<code-php>
$TLS_btn_activate = "Активировать";
$TLS_btn_del = "Удалить";
$TLS_btn_edit_del = "Править / Удалить";
$TLS_btn_inactivate = "Деактивировать";
$TLS_caption_edit_product = "Править проект";
$TLS_caption_new_product = "Создать проект";
$TLS_color = "Цвет";
$TLS_enable_requirements = "Включить функциональность Требований";
$TLS_info_failed_loc_prod = "Не удалось локализовать проект.";
$TLS_notes = "Заметки";
// Warning!!! - if JS string you must use \\n to get \n
$TLS_popup_product_delete = <<<END
Внимание! Вы собираетесь необратимо удалить все данные связанные проектом:
результаты тестов, планы тестирования, тесты и т.п. \\n
Вместо удаления вы можете деактивировать проект. \\n
Если вы всё-таки настроены удалить проект, рекомендуем вам сначала
сделать бэкап базы данных. \\n
Итак, вы по прежнему уверены удалить проект?
END;
$TLS_warning_empty_tproject_name = "Обязательно задайте имя проекта!";
</code-php>

==gui/templates/reqAssign.tpl==
<code-php>
$TLS_please_select_a_req = "Пожалуйста, выберите требование";
$TLS_req_msg_norequirement66 = "Требования нет";
$TLS_req_title_assign = "Привяжите требования к тесту";
$TLS_req_title_assigned = "Привязанные требования";
$TLS_req_title_unassigned = "Доступные требования";
$TLS_warning_req_tc_assignment_impossible = <<<END
<p>
Вы <b>не можете</b> делать привязку по одной из следующих причин:
<ul>
<li>Не определено ни одной спецификации требования;
<li>Спецификации требований пусты.
</ul>
END;
</code-php>

==gui/templates/tcEdit.tpl==
<code-php>
$TLS_title_edit_tc = "Править тест";
$TLS_warning_editing_executed_tc = "Внимание: Этот версия теста уже выполнялась";
</code-php>

==gui/templates/planOwner.tpl==
<code-php>
$TLS_assign_ownership = "Назначить ответственного";
$TLS_def_prio_rules = "Определить правила приоритетов";
$TLS_opt_label_none = "нет";
$TLS_th_imp = "Важность";
$TLS_th_owner = "Тестировщик";
$TLS_th_risk = "Риск";
$TLS_th_test_suite = "Группа тестов";
$TLS_title_plan_ownership = "Владелец плана тестирования";
</code-php>

==gui/templates/tcView_viewer.tpl==
<code-php>
$TLS_activate_this_tcversion = "Активировать эту версию";
$TLS_Requirements = "Требования";
$TLS_btn_del_this_version = "Удалить эту версию";
$TLS_btn_edit = "Править";
$TLS_btn_mv_cp = "Переместить/Копировать";
$TLS_btn_new_version = "Создать новую версию";
$TLS_can_not_edit_tc = "Вы не можете редактировать эту версию, т.к. она уже выполнялась";
$TLS_deactivate_this_tcversion = "Деактивировать эту версию";
$TLS_tcversion_is_inactive_msg = "Эта версия <b>неактивна</b>, и не будет доступна для включения в план тестирования";
</code-php>

==gui/templates/planRemoveTC_m1.tpl==
<code-php>
$TLS_btn_remove_selected_tc = "Удалить выбранные тесты tcs";
$TLS_remove_ok = "Удаление прошло успешно ok";
$TLS_title_remove_test_from_plan = "Удалить тест из плана тестирования";
</code-php>

==gui/templates/planTesters.tpl==
<code-php>
$TLS_btn_save = "Сохранить";
</code-php>

==gui/templates/keywordsAssign.tpl==
<code-php>
$TLS_keyword_assignment_empty_tsuite = "В этой группе тестов нет тестов => ключевое слово привязать нельзя";
$TLS_menu_assign_kw_to_tc = "Привязать к тестам";
$TLS_menu_manage_keywords = "Управление ключевыми словами";
$TLS_title_keywords = "Ключевые слова";
</code-php>

==gui/templates/planTestersNavigator.tpl==
<code-php>
$TLS_label_list_of = "Список ";
$TLS_opt_test_plans = "планов тестирования";
$TLS_opt_users = "пользователей";
</code-php>

==gui/templates/planUpdateTC.tpl==
<code-php>
$TLS_btn_upd_ck_tc = "Изменить выбранные тест(ы)";
$TLS_info_all_tc_uptodate = "Все тесты актуальны.";
$TLS_th_category = "Группа тестов";
$TLS_th_component = "Группа тестов";
$TLS_th_id_tc = "[ID] теста";
$TLS_th_reason = "Причина правки";
$TLS_th_spec_version = "Специальная версия";
$TLS_th_status = "Состояние";
$TLS_th_suite_version = "Версия группы тестов";
$TLS_th_update = "Изменить";
$TLS_title_upd_mod_tc = "Изменить исправленные тесты в ";
</code-php>

==gui/templates/keywordsView.tpl==
<code-php>
$TLS_alt_delete_keyword = "Удалить ключевое слово?";
$TLS_btn_create_keyword = "Создать ключевое слово";
$TLS_btn_edit_keyword = "Править";
$TLS_btn_import_keywords = "Импорт";
$TLS_th_keyword = "Ключевое слово";
$TLS_warning_delete_keyword = "Вы уверены удалить ключевое слово?";
$TLS_warning_enter_at_least1 = "Пожалуйста, введите хотя бы ";
$TLS_warning_enter_at_least2 = " символов.";
$TLS_warning_enter_less1 = "Пожалуйста, используйте не больше чем";
$TLS_warning_enter_less2 = " символов.";
</code-php>

==gui/templates/reqexport.tpl==
<code-php>
$TLS_title_req_export_to = "Экспорт требований";
</code-php>

==gui/templates/resultsAllBuilds.tpl==
<code-php>
$TLS_test_status_blocked = "Блокирован";
$TLS_test_status_failed = "Сбой";
$TLS_test_status_passed = "Пройден";
$TLS_th_build = "Сборка";
$TLS_th_tc_total = "Всего тестов";
</code-php>

==gui/templates/resultsBugs.tpl==
<code-php>
$TLS_date = "Дата:";
$TLS_printed_by = "Напечатано:";
$TLS_title_test_case_bugs = "Баги по тесту";
$TLS_title_test_case_timestamp = "Временная метка теста";
$TLS_title_test_case_title = "Заголовок теста";
$TLS_title_test_suite_name = "Имя группы тестов";
</code-php>

==gui/templates/resultsBuild.tpl==
<code-php>
$TLS_title_met_of_build = "Метрики сборки";
</code-php>

==gui/templates/resultsByStatus.tpl==
<code-php>
$TLS_info_test_results = <<<END
<p>
Показываются результаты только последнего теста.
<p>
В частности, тесты скрыты, если результаты тестов для следующей сборки
имеют статус отличный от "в процессе".
END;

$TLS_th_bugs = "Баги";
$TLS_th_date = "Дата";
$TLS_th_run_by = "Запустил:";
</code-php>

==gui/templates/resultsGeneral.tpl==
<code-php>
$TLS_title_gen_test_rep = "Общие метрики плана тестирования";
</code-php>

==gui/templates/resultsMoreBuilds_query_form.tpl==
<code-php>
$TLS_excel_format = "MS Excel";
$TLS_html_format = "HTML";
$TLS_last_status_any = "Любой";
$TLS_last_status_blocked = "Блокирован";
$TLS_last_status_failed = "Сбой";
$TLS_last_status_not_run = "Не стартовал";
$TLS_last_status_passed = "Пройден";
$TLS_select_builds_header = "Выберите сборку(и)";
$TLS_select_components_header = "Выберите группу тестов";
$TLS_select_keyword_header = "Выберите ключевое слово";
$TLS_select_last_result_header = "Выберите последний результат";
$TLS_select_owner_header = "Выберите владельца";
$TLS_select_report_format_header = "Выберите формат отчета";
$TLS_submit_query = "Выполнить запрос";
$TLS_test_plan_header = "План тестирования: ";
$TLS_query_metrics_report = "Запросить отчет по метрикам";
$TLS_enter_start_time = "Введите начальное время";
$TLS_enter_end_time = "Введите конечное время";
$TLS_year = "год";
$TLS_month = "месяц";
$TLS_day = "день";
$TLS_hour = "час";
$TLS_search_in_notes = "поиск строки в заметках";
$TLS_executor = "исполнитель";
</code-php>

==gui/templates/resultsMoreBuilds_report.tpl==
<code-php>
$TLS_caption_show_collapse = "Показать/Свернуть";
$TLS_caption_user_selected_query_parameters = "Параметры запроса";
$TLS_not_yet_executed = "Еще не выполнялся";
$TLS_show_hide_all = "Показать/Скрыть все";
$TLS_th_builds = "Сборка(и)";
$TLS_th_execution_ts = "Время";
$TLS_th_last_result = "Последний результат";
$TLS_th_report_format = "Тип отчета";
$TLS_th_test_plan = "План тестирования";
$TLS_th_test_suites = "Группа(ы) тестов";
$TLS_th_tester_id = "Тестировщик";
$TLS_th_total_block = "# блокированных ";
$TLS_th_total_cases = "# тестов";
$TLS_th_total_fail = "# сбоев";
$TLS_th_total_not_run = "# не стартовавших";
$TLS_th_total_pass = "# выполненных";
$TLS_th_start_time = "Время начала";
$TLS_th_end_time = "Время окончания";
$TLS_th_executor = "Исполнитель";
$TLS_th_search_notes_string = "в заметках искать строку";
$TLS_true = "да";
$TLS_false = "нет";
$TLS_display_suite_summaries = "Показать итоги по группе тестов";
$TLS_display_query_params = "Показать параметры запроса";
$TLS_display_totals = "Показать суммарную информацию";
</code-php>

==gui/templates/resultsReqs.tpl==
<code-php>
$TLS_req_title_blocked = "Заблокировано требований";
$TLS_req_title_failed = "Нарушено требований";
$TLS_req_title_notrun = "Непроверенных требований";
$TLS_req_title_passed = "Выполнено требований";
$TLS_title_result_req_testplan = "Результаты тестов основанных на спецификации требований";
$TLS_title_test_plan = "План тестирования";
</code-php>

==gui/templates/resultsSend.tpl==
<code-php>
$TLS_btn_send_report = "Послать отчет";
$TLS_check_send_to_me = "Послать отчет самому себе";
$TLS_mail_body = "Тело письма:";
$TLS_mail_report = "Отчет:";
$TLS_mail_subject = "Тема письма:";
$TLS_mail_to = "Кому:";
$TLS_status_for_build = "Состояние сборки";
$TLS_tp_status = "Общее состояние плана тестирования";
$TLS_tp_status_for_build = "Состояние плана тестирования для сборки";
</code-php>

==gui/templates/resultsTC.tpl==
<code-php>
$TLS_generated_by_TestLink_on="Сформировано системой TestLink, ";
</code-php>

==gui/templates/tcEdit_m2.tpl==

==gui/templates/tcPrintNavigator.tpl==
<code-php>
$TLS_caption_print_opt = "Настройки печати";
$TLS_tr_td_show_as = "Показать как";
</code-php>

==gui/templates/tcReorder.tpl==
<code-php>
$TLS_no_tc_to_reorder = "Нет тестов для переупорядочивания.";
$TLS_title_change_tc_order = "Изменить порядок тестов в этой группе тестов.";
</code-php>

==gui/templates/tcTree.tpl==
<code-php>
$TLS_button_refresh = "Обновить";
$TLS_button_update_tree = "Обновить дерево";
$TLS_do_auto_update = "Обновлять дерево после каждой операции";
$TLS_no_tc_spec_av = "Нет тест-спецификаций.";
</code-php>

==gui/templates/tc_exec_assignment.tpl==
<code-php>
$TLS_btn_do = "Пуск";
$TLS_btn_update_selected_tc = "Изменить выбранные тесты";
$TLS_title_tc_exec_assignment = "Назначить прогоны тестов для плана тестирования ";
$TLS_user = "Пользователь";
$TLS_user_bulk_assignment = "Массовое назначение ответственных пользователей";
</code-php>

==gui/templates/testSetNavigator.tpl==

==gui/templates/userInfo.tpl==
<code-php>
$TLS_btn_change_passwd = "Сменить пароль";
$TLS_btn_upd_user_data = "Изменить";
$TLS_th_new_passwd = "Новый пароль";
$TLS_th_new_passwd_again = "Повторите новый пароль";
$TLS_th_old_passwd = "Старый пароль";
$TLS_title_account_settings = "Настройки профиля";
$TLS_title_change_your_passwd = "Сменить ваш пароль";
$TLS_warning_different_pwd = "Пожалуйста, повторите еще раз ваш новый пароль. Введенные пароли не совпадают.";
$TLS_warning_empty_pwd = "Пароль должен быть не пуст!";
$TLS_your_password_is_external = "Ваш пароль ведётся во внешней системе";
</code-php>

==gui/templates/usersassign.tpl==
<code-php>
$TLS_TestProject = "проект";
$TLS_User = "Пользователь";
$TLS_btn_change = "Изменить";
$TLS_caption_assign_testplan_user_roles = "Назначить роли плана тестирования пользователям";
$TLS_caption_assign_testproject_user_roles = "Назначить роли проекта пользователям";
$TLS_menu_assign_testproject_roles = "Назначить роли проекта";
$TLS_th_roles = "Роли";
$TLS_title_assign_roles = "Назначить роли";
</code-php>

==gui/templates/usersedit.tpl==
<code-php>
$TLS_button_reset_password = "Сбросить пароль";
$TLS_caption_user_details = "Свойства пользователя";
$TLS_th_password = "Пароль";
$TLS_warning_empty_first_name = "Пожалуста, введите имя";
$TLS_warning_empty_last_name = "Пожалуйста, введите фамилию";
$TLS_warning_empty_login = "Пожалуйста, введите логин";
</code-php>

==gui/templates/attachmentupload.tpl==
<code-php>
$TLS_attachment_upload_ok="Файл загружен.";
$TLS_enter_attachment_title = "Введите заголовок для этого вложения.";
$TLS_import_was_ok = "Импорт прошел успешно.";
$TLS_max_size_cvs_file = "Максимальный размер файла:";
$TLS_title_upload_attachment = "Загрузить вложение";
</code-php>

==gui/templates/rolesview.tpl==
<code-php>
$TLS_N_A = "N/A";
$TLS_alt_delete_role = "Удалить роль";
$TLS_alt_edit_role = "Править роль";
$TLS_btn_confirm_delete = "Удалить";
$TLS_no_roles = "Нет ролей";
$TLS_title_roles = "Доступные роли";
$TLS_warning_users_will_be_reset = "'Задетым пользователям' будет назначена гостевая роль!";
</code-php>

==gui/templates/tcexport.tpl==
<code-php>
$TLS_export_with_keywords = "Экспортировать с ключевыми словами";
</code-php>

==gui/templates/buildView.tpl==
<code-php>
$TLS_alt_active_build = "Активная сборка";
$TLS_alt_edit_build = "Редактировать эту сборку";
$TLS_alt_open_build = "Открыть сборку";
$TLS_btn_build_create = "Создать";
$TLS_no_builds = "В этот плане тестирования сборок не определено.";
$TLS_th_description = "Описание";
$TLS_th_open = "Открыть";
$TLS_title_build_list = "Список существующих сборок";
$TLS_warning_delete_build = <<<END
<p>Вы действительно хотите уничтожить эту сборку? <p>
Все связанные данные (в частности, результаты тестов) будут также удалены!";
END;
</code-php>

==gui/templates/planView.tpl==
<code-php>
$TLS_testplan_alt_delete_tp = "Удалить этот план тестирования?";
$TLS_testplan_alt_edit_tp = "Править план тестирования";
$TLS_testplan_msg_delete_confirm = <<<END
Вы уверены, что хотите удалить план тестирования? <p>
План тестирования можно деактивировать не удаляя.
END;

$TLS_testplan_th_delete = "Удалить";
$TLS_testplan_title_list = "Список планов тестирования";
$TLS_testplan_txt_empty_list = <<<END
Ни одного плана тестирования не определено! <p>
Чтобы воспользоваться функциональностью прогонов тестов, нужно
создать хотя бы один.
END;
$TLS_alt_active_testplan = "Активный план тестирования";
</code-php>

==gui/templates/mainPage_left.tpl==
<code-php>
$TLS_href_assign_user_roles = "Назначить пользовательские роли";
$TLS_href_browse_tc = "Просмотр тестов";
$TLS_href_cfields_management = "Управление пользовательскими полями";
$TLS_href_cfields_tproject_assign = "Привязка пользовательских полей";
$TLS_href_create_product = "Создать новый проект";
$TLS_href_edit_product = "Править/Удалить проект";
$TLS_href_edit_tc = "Редактировать тесты";
$TLS_href_keywords_assign = "Привязать ключевые слова";
$TLS_href_keywords_manage = "Управление ключевыми словами";
$TLS_href_keywords_view = "Просмотр ключевых слов";
$TLS_href_print_tc = "Печать тестов";
$TLS_href_req_assign = "Привязать требования";
$TLS_href_req_spec = "Спецификация требований";
$TLS_href_roles_management = "Управление ролями";
$TLS_href_search_tc = "Искать тест(ы)";
$TLS_href_user_management = "Управление пользователями";
$TLS_title_requirements = "Требования";
$TLS_title_test_spec = "Спецификации тестов";
$TLS_title_product_mgmt = "Управление проектами";
</code-php>

==gui/templates/mainPage_right.tpl==
<code-php>
$TLS_filter_tp_by_product = "Фильтровать план тестирования по проектам";
$TLS_href_add_test_case = "Добавить тест(ы)";
$TLS_href_build_new = "Управление сборками";
$TLS_href_execute_test = "Выполнить тесты";
$TLS_href_plan_assign_priority = "Установить приоритеты";
$TLS_href_plan_define_priority = "Определить правила приоритетов";
$TLS_href_plan_management = "Управление планами тестирования";
$TLS_href_plan_mstones = "Управление вехами";
$TLS_href_print_tc_suite = "Печать плана тестирования";
$TLS_href_remove_test_case = "Удалить тест(ы)";
$TLS_href_rep_and_metrics = "Отчеты и метрики";
$TLS_href_tc_exec_assignment = "Поручить прогон тестов";
$TLS_href_upd_mod_tc = "Сохранить измененные тесты";
$TLS_msg_no_rights_for_tp = "- недоступен (У вас нет доступа ни для одного плана тестирования)";
$TLS_testplan_role = "Роль плана тестирования";
$TLS_title_test_case_suite = "Содержание плана тестирования";
$TLS_title_test_execution = "Выполнение плана тестирования";
$TLS_title_test_plan_mgmt = "Управление планами тестирования";
$TLS_href_newest_tcversions = "Показать тесты с самыми свежими версиями";
</code-php>

==lib/execute/bug_add.php==
<code-php>
$TLS_bug_added = "Баг добавлен";
$TLS_error_bug_does_not_exist_on_bts="Бага с таким ID не зарегистрировано в BTS!";
$TLS_error_wrong_BugID_format = "Неверный формат BugID!";
</code-php>

==lib/execute/bug_delete.php==
<code-php>
$TLS_bugdeleting_was_ok = "Баг успешно удален.";
</code-php>

==lib/functions/doAuthorize.php==
<code-php>
$TLS_error_ldap_auth_failed = "LDAP-аутентификация не удалась";
$TLS_error_ldap_bind_failed = "Не удалось выполнить LDAP-binding";
$TLS_error_ldap_server_connect_failed = "Не удалось соединится с LDAP-сервером";
$TLS_error_ldap_update_failed = "Обновление LDAP не удалось";
$TLS_error_ldap_user_not_found = "LDAP-пользователь не найден";
</code-php>

==lib/functions/product.inc.php==
<code-php>
$TLS_info_product_delete_fails = "При удалении этого проекта произошла ошибка";
</code-php>

==lib/functions/results.inc.php==
<code-php>
$TLS_trep_failing = "Провалены";
$TLS_trep_passing = "Прошли";
$TLS_trep_status_for_build = "Состояние для сборки";
$TLS_trep_status_for_ts = "Состояние для группы тестов";
$TLS_unassigned = "Не назначены";
</code-php>

==lib/functions/resultsMoreBuilds.inc.php==
<code-php>
$TLS_bugs = "Связанные Баги";
$TLS_builds_selected = "Сборка(и)";
$TLS_case_not_run_warning = "Тест не запущен";
$TLS_category_header = "Группа тестов =";
$TLS_daterun = "Дата запуска";
$TLS_last_status = "Последнее состояние";
$TLS_number_blocked = "# блокированных";
$TLS_number_cases = "# тестов";
$TLS_number_executions = "# тест-пусков";
$TLS_number_failed = "# тест-сбоев";
$TLS_number_not_run = "# не запущено";
$TLS_number_passed = "# пройденных";
$TLS_owner = "Тестировщик";
$TLS_owner_header = "Tester =";
$TLS_runby = "Запущен тестировщиком ";
$TLS_test_plan_name = "План тестирования";
</code-php>

==lib/functions/roles.inc.php==
<code-php>
$TLS_desc_cfield_management = "Управление пользовательскими полями";
$TLS_desc_cfield_view = "Просмотр пользовательских полей (read-only)";
$TLS_desc_mgt_modify_key = "Управление ключевыми словами";
$TLS_desc_mgt_modify_product= "Управление проектами";
$TLS_desc_mgt_modify_req = "Управление требованиями";
$TLS_desc_mgt_modify_tc = "Создание/правка тестов";
$TLS_desc_mgt_modify_users = "Управление пользователями";
$TLS_desc_mgt_view_key = "Просмотр ключевых слов (read-only)";
$TLS_desc_mgt_view_req = "Просмотр требований (read-only)";
$TLS_desc_mgt_view_tc = "Просмотр тестов (read-only)";
$TLS_desc_role_management = "Управление ролями";
$TLS_desc_testplan_create_build = "Создание/редактирование сборки";
$TLS_desc_testplan_execute = "Выполнение плана тестирования";
$TLS_desc_testplan_metrics = "Метрики плана тестирования";
$TLS_desc_testplan_planning = "Составление плана тестирования";
$TLS_desc_user_role_assignment = "Назначение ролей";
$TLS_error_duplicate_rolename = "Роль с таким именем уже есть!";
$TLS_error_role_no_rights = "Вы не можете создать роль без каких-либо прав!";
$TLS_error_role_no_rolename = "Вам нужно ввести имя для этой роли.";
$TLS_mgt_testplan_create = "Создать/править план тестирования";
</code-php>

==lib/functions/testproject.class.php==
<code-php>
$TLS_error_creating_req_spec = "Ошибка при создании спецификации требования";
$TLS_info_product_name_empty = "Нельзя давать пустое имя.";
$TLS_keyword_already_exists = "Такое ключевое слово уже есть";
$TLS_string_contains_bad_chars = "Введенная строка содержит недопустимые символы.";
$TLS_warning_duplicate_req_title= "Требование с таким заголовком уже есть.";
</code-php>

==lib/functions/requirements.inc.php==
<code-php>
$TLS_conflict = "Конфликт";
$TLS_error_deleting_req = "Ошибка при удалении требования(й).";
$TLS_error_inserting_req = "Ошибка при вставке требования(й).";
$TLS_error_updating_req = "Ошибка при правке требования(й).";
$TLS_error_updating_reqspec = "Ошибка при правке спецификаций требований.";
$TLS_file_is_not_xml = "Файл не распознан как корректный XML, и не может быть использован.";
$TLS_ok = "OK";
$TLS_req_import_format_description1 = " - тип CSV требует три поля на каждую запись: 'req_doc_id','title','description'";
$TLS_req_import_format_description2 = " - CSV, экспортированный из DOORS требует запись-заголовок.";
$TLS_req_import_result_overwritten = "перезаписано!";
$TLS_req_import_result_skipped = "пропущено";
$TLS_req_state_not_testable = "не тестируемо";
$TLS_req_state_valid = "актуально";
$TLS_the_format_req_xml_import = "Неверный XML-формат для импорта требований";
$TLS_warning_duplicate_reqdoc_id = "Не уникальный (дублирующий) id документа";
</code-php>

==lib/functions/testsuite.class.php==
<code-php>
$TLS_component_name_already_exists = "Группа тестов с таким именем уже зарегистрирована";
$TLS_testsuite = "Группа тестов";
</code-php>

==lib/functions/exec.inc.php==
<code-php>
$TLS_test_results_submitted = "Результаты тестов отправлены.";
</code-php>

==lib/functions/print.inc.php==
<code-php>
$TLS_author = "Автор";
$TLS_printed_by_TestLink_on = "Распечатано TestLink'ом ";
$TLS_title_toc = "Содержание";
$TLS_passfail = "Пройден / Провален";
$TLS_testnotes = "Заметки к тесту";
</code-php>

==lib/functions/testcase.class.php==
<code-php>
$TLS_testcase_name_already_exists = "Тест с таким именем уже есть!";
$TLS_the_format_tc_xml_import = "";
</code-php>

==lib/functions/info.inc.php==
<code-php>
$TLS_email_sent_message = "Ваше письмо отослано.";
</code-php>

==lib/functions/users.inc.php==
<code-php>
$TLS_Unknown = "Неизвестно";
$TLS_duplicate_login = "Пользователь с таким логином уже есть!";
$TLS_login_must_not_be_empty = "Логин не должен быть пустым!";
$TLS_wrong_old_password = "Старый пароль неверен!";
</code-php>

==lib/functions/email_api.php==
<code-php>
$TLS_stmp_host_unconfigured = "Некорректно указан SMTP host!";
</code-php>

==lib/functions/common.php==

==lib/functions/configCheck.php==
<code-php>
$TLS_attachments_dir = "каталог для вложений:";
$TLS_bts_connection_problems = <<<END
Не удалось соединиться с вашей Bug Tracking System.<p>
Пожалуйста, проверьте настройки.<p>
Будьте внимательны, эта проблема
снижает производительность TestLink'а.
END;

$TLS_but_directory_is_not_writable = "Каталог закрыт для записи!";
$TLS_directory_is_writable = "Каталог открыт для записи.";
$TLS_does_not_exist = "не существует";
$TLS_exists = "существует";
$TLS_ldap_extension_not_loaded=<<<END
Метод аутентификации указан как LDAP </br>
однако PHP/LDAP extension не загружено =>
Вам не удастся войти в систему.
Пожалуйста, свяжитесь с администратором TestLink'а.
END;
$TLS_sec_note_admin_default_pwd = "Вам необходимо сменить пароль по умолчанию у пользователя 'admin'!";
$TLS_sec_note_remove_install_dir = "Инсталляционный каталог должен быть удален!";
</code-php>

==lib/general/frmWorkArea.php==
<code-php>
$TLS_create_a_build = "Создать новую сборку";
$TLS_no_build_warning_part1 = "Ни одной сборки для этого тест плана не создано.";
$TLS_no_build_warning_part2 = "Создайте их или попросите об этом свое руководство.";
</code-php>

==lib/general/myTPInfo.php==
<code-php>
$TLS_no_testplans_available = "К сожалению, ни одного плана тестирования не доступно";
</code-php>

==lib/general/tlsmarty.inc.php==

==lib/keywords/keywords.inc.php==
<code-php>
$TLS_empty_keyword_no = "Ключевое слово должно быть непустым!";
$TLS_keywords_char_not_allowed = "Запятые и кавычки недопустимы в ключевых словах!";
$TLS_tc_kw_update_fails1 = "Тест";
$TLS_tc_kw_update_fails2 = " дал сбой ";
$TLS_the_format_keyword_csv_import = "keyword;notes";
$TLS_the_format_keyword_xml_import = "<keywords><keyword name=\"name\">Notes</keyword></keywords>";
</code-php>

==lib/keywords/keywordsView.php==
<code-php>
$TLS_kw_delete_fails = "Не удалось удаление ключевого слова!";
$TLS_kw_update_fails = "Не удалась правка ключевого слова!";
</code-php>

==lib/keywords/keywordsAssign.php==
<code-php>
$TLS_assigned_kword = "Связанные ключевые слова";
$TLS_available_kword = "Доступные ключевые слова";
</code-php>

==lib/plan/buildNew.php==
<code-php>
$TLS_cannot_add_build = "Невозможно добавить сборку!";
$TLS_cannot_delete_build = "Невозможно удалить сборку!";
$TLS_cannot_update_build = "Ошибка при правке сборки!";
$TLS_warning_duplicate_build = "Сборка с таким идентификатором уже есть.";
</code-php>

==lib/plan/plan.inc.php==
<code-php>
$TLS_warning_empty_milestone_name = "Обязательно введите имя для вехи!";
$TLS_warning_enter_valid_date = "Введенная дата некорректна!";
$TLS_warning_invalid_percentage_value = "Значения-проценты должны быть от 0 to 100 (%)";
$TLS_warning_milestone_date = "Веха не может иметь дату раньше чем 'сегодня'!";
$TLS_warning_percentage_value_higher_than_100 = "Сумма всех значений-процентов не должна быть больше 100!";
</code-php>

==lib/plan/planMilestones.php==
<code-php>
$TLS_milestone_delete_fails = "Не удалось удалить веху!";
$TLS_warning_milestone_add_failed = "Не удалось добавить веху!";
$TLS_warning_milestone_update_failed = "Не удалось править веху!";
</code-php>

==lib/plan/planOwner.php==
<code-php>
$TLS_opt_imp_high = "Высокая";
$TLS_opt_imp_low = "Низкая";
$TLS_opt_imp_medium = "Средняя";
</code-php>

==lib/plan/planTestersEdit.php==
<code-php>
$TLS_title_assign_tp = "Поручить планы тестирования пользователю: ";
$TLS_title_assign_users = "Назначить пользователей на план тестирования: ";
</code-php>

==lib/plan/planTestersNavigator.php==
<code-php>
$TLS_nav_test_plan = "Навигатор - Планы тестирования";
$TLS_nav_users = "Навигатор - Пользователи";
</code-php>

==lib/plan/planUpdateTC.php==
<code-php>
$TLS_category_has_changed = "Группа тестов изменена";
$TLS_component_has_changed = "Группа тестов изменена";
$TLS_deleted = "удалена";
$TLS_different_versions = "Различные версии";
$TLS_plan_update_no_tc_updated = "Ни один тест не изменен";
$TLS_planupdate_tc_deleted1 = "Тест";
$TLS_planupdate_tc_deleted2 = "был удален.";
$TLS_planupdate_tc_updated1 = "Тест";
$TLS_planupdate_tc_updated2 = "был изменен.";
$TLS_tcorder_has_changed = "Порядок тестов был изменен";
$TLS_updated = "изменен";
</code-php>

==lib/plan/testSetNavigator.php==
<code-php>
$TLS_title_test_plan_navigator = "Навигация по планам тестирования";
</code-php>

==lib/plan/testSetRemove.php==
<code-php>
$TLS_tcase_removed_from_tplan="тест удален из плана тестирования";
$TLS_multiple_tcase_removed_from_tplan="Тесты удалены из плана тестирования";
</code-php>

==lib/plan/planEdit.php==
<code-php>
$TLS_testplan_created_ok = "План тестирования был создан";
$TLS_update_tp_failed1 = "Правка плана тестирования '";
$TLS_update_tp_failed2 = "' не удалась";
$TLS_warning_duplicate_tplan_name = "План тестирования с таким именем уже есть. Выберите другое имя!";
</code-php>

==lib/print/selectData.php==
<code-php>
$TLS_opt_show_doc_header = "Показать заголовок документа";
$TLS_opt_show_tc_body = "Показать тело теста";
$TLS_opt_show_tc_summary = "Показать резюме теста";
$TLS_opt_show_toc = "Показать Содержание";
$TLS_opt_show_tc_author = "Показать автора теста";
$TLS_opt_show_passfail = "Показать статус «пройден/провален» и заметки";
$TLS_title_tc_print_navigator = "Навигация - Печать спецификации тестов";
$TLS_title_tp_print_navigator = "Навигация - Печать плана тестирования";
</code-php>

==lib/project/projectedit.php==
<code-php>
$TLS_error_product_name_duplicate = "Уже есть проект с именем %s. <br>Пожалуйста, выберите другое имя";
$TLS_info_no_more_prods = "проектов больше нет.";
$TLS_info_product_activated = "проект активирован.";
$TLS_info_product_inactivated = "проект деактивирован.";
$TLS_info_product_not_deleted_check_log = "Не удалось удалить проект. Проверьте лог TestLink'а.";
$TLS_info_product_was_deleted = "проект успешно удален.";
$TLS_refer_to_log = " Пожалуйста, изучите лог TestLink'а для дополнительной информации.";
$TLS_test_project_activated = "проект %s успешно активирован";
$TLS_test_project_created = "проект %s успешно создан";
$TLS_test_project_deleted = "проект %s успешно удален";
$TLS_test_project_inactivated = "проект %s успешно деактивирован";
$TLS_test_project_updated = "проект %s успешно отредактирован";
$TLS_test_project_update_failed = "Правка проекта %s не удалась!";
</code-php>

==lib/results/charts.php==
<code-php>
$TLS_maani_copyright = "flash technology предоставлена http://www.maani.us";
$TLS_graphical_reports = "Графические отчеты";
$TLS_overall_metrics = "Общие метрики";
$TLS_results_by_keyword = "Результаты по ключевому слову";
$TLS_results_by_tester = "Рузультаты по тестировщику";
$TLS_results_top_level_suites = "Результаты по топ группам тестов";
</code-php>

==lib/req/reqImport.php==
<code-php>
$TLS_file_is_not_ok_for_import_type = "Кажется тип файла не совпадает с выбранным для импорта типом";
$TLS_file_is_not_text = "Это не текстовый файл. Использовать нельзя.";
$TLS_please_choose_req_file = "Пожалуйста, выберите файл для загрузки";
$TLS_req_import_finished = "Импорт завершен!";
</code-php>

==lib/req/reqSpecView.php==
<code-php>
$TLS_cant_create_tc_from_req_nothing_sel = "Пожалуйста, выберите требование!";
$TLS_req_created = "Требование %s успешно создано.";
</code-php>

==lib/req/reqTcAssign.php==
<code-php>
$TLS_req_msg_noselect = "Ничего не выбрано";
$TLS_req_msg_notupdated_coverage = "Покрытие не обновлено для Требований: ";
</code-php>

==lib/results/resultsBugs.php==
<code-php>
$TLS_title_test_report_all_builds = "Отчет: Результаты тестов для всех сборок";
</code-php>

==lib/results/resultsAllBuilds.php==
<code-php>
$TLS_title_metrics_x_build = " - Результаты тестов. Метрики X Сборки";
</code-php>

==lib/results/resultsByStatus.php==
<code-php>
$TLS_list_of_blocked = "Список блокированных тестов";
$TLS_list_of_failed = "Список проваленных тестов";
$TLS_list_of_not_run = "Список незапущенных тестов";
</code-php>

==lib/results/resultsTC.php==

==lib/results/resultsNavigator.php==
<code-php>
$TLS_link_charts="Диаграммы";
$TLS_link_report_blocked_tcs = "Блокированные тесты";
$TLS_link_report_failed = "Проваленные тесты";
$TLS_link_report_general_tp_metrics = "Общие метрики плана тестирования";
$TLS_link_report_metrics_active_build = "Метрики активной сборки";
$TLS_link_report_metrics_more_builds = "Запрос метрик";
$TLS_link_report_not_run="Не запущенные тесты";
$TLS_link_report_overall_build = "Общий статус всех сборок";
$TLS_link_report_reqs_coverage = "Отчет о выполнении требований";
$TLS_link_report_test = "Отчет по тестам";
$TLS_link_report_total_bugs = "Всего багов по каждому тесту";
</code-php>

==lib/results/resultsSend.php==
<code-php>
$TLS_send_to_empty_email_warning = "Пожалуйста, введите правильный email.";
$TLS_warning_create_build_first = "Сначала Вы должны создать или импортировать сборки.";
</code-php>

==lib/results/displayMgr.php==
<code-php>
$TLS_error_sendreport_no_email_credentials = "Email для этого пользователя не указан, пожалуйста, укажите его в настройках своего профиля";
</code-php>

==lib/testcases/archive.inc.php==

==lib/testcases/listTestCases.php==

==lib/testcases/tcImport.php==
<code-php>
$TLS_please_choose_file_to_import = "Пожалуйста, выберите файл для импорта";
$TLS_title_tc_import_to = "Импорт тестов";
$TLS_title_tsuite_import_to = "Импорт группы тестов";
$TLS_wrong_xml_tcase_file = "Некорректный XML в файле с тестами";
$TLS_wrong_xml_tsuite_file = "Некорректный XML в файле с группой тестов";
</code-php>

==lib/testcases/tcexport.php==
<code-php>
$TLS_no_testcases_to_export = "Нет тестов для экспорта";
$TLS_no_testsuites_to_export = "Нет группы тестов для экспорта";
$TLS_title_tc_export = "Экспорт теста";
$TLS_title_tc_export_all = "Экспортировать все тесты";
$TLS_title_tsuite_export = "Экспортировать все группы тестов";
$TLS_title_tsuite_export_all = "Экспортировать все группы тестов";
</code-php>

==lib/testcases/containerEdit.php==
<code-php>
$TLS_delete = "Удалить";
$TLS_delete_notice = "Внимание: Все связанные результаты прогонов будут удалены";
$TLS_warning_empty_com_name = "Пожалуйста, задайте имя для группы тестов";
</code-php>

==lib/testcases/tcEdit.php==
<code-php>
$TLS_current = "текущий";
$TLS_delete_linked = "Ссылки на планы тестирования будут удалены.";
$TLS_delete_linked_and_exec = "Ссылки на планы тестирования и результаты выполнения будут удалены.";
$TLS_error_tc_add = "При добавлении теста произошла ошибка";
$TLS_title_del_tc = "Удалить тест ";
</code-php>

==lib/usermanagement/rolesview.php==
<code-php>
$TLS_error_role_deletion = "Не удалось удалить роль!";
</code-php>

==lib/usermanagement/usersassign.php==
<code-php>
$TLS_no_test_projects = "Не заведено ни одного проекта";
$TLS_no_test_plans = "Для этого проекта не заведено ни одного плана тестирования";
$TLS_test_project_user_roles_updated = "Пользовательские роли обновлены";
$TLS_test_plan_user_roles_updated = "Пользовательские роли обновлены";
</code-php>

==lib/usermanagement/usersedit.php==
<code-php>
$TLS_user_created="Пользователь %s был успешно создан";
$TLS_user_deleted="Пользователь %s был успешно удален";
$TLS_user_not_added = "Не удалось добавить пользователя!";
</code-php>

==lib/usermanagement/rolesedit.php==
<code-php>
$TLS_error_role_creation = "Не удалось создать роль!";
$TLS_error_role_update = "Не удалось исправить роль!";
</code-php>

==lib/cfields/cfields_edit.php==
<code-php>
$TLS_cf_name_exists = "Пользовательское поле с таким именем уже существует. Пожалуста, выберите другое имя.";
$TLS_error_creating_cf = "Не удалось создать пользовательское поле!";
$TLS_do_update = "исправлено";
$TLS_do_delete = "удалено";
$TLS_do_add = "добавлено";
</code-php>

==resultsBugs.tpl==
<code-php>
$TLS_Open="Открыто";
$TLS_Resolved="Исправленных";
$TLS_Total="Всего";
$TLS_TCs_with_Bugs="Тестов с багами";
</code-php>

TestLink

2007-10-05T13:12:26Z

Andrew: /* Основные понятия */

[[Category:TestLink]]

[[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="Тэг (ключевое слово)"];
Build [label="Сборка"];
TestLog [label="Результат теста"];
Bug [label="Отчет об ошибке" fillcolor="green"];

Product->TestSpec [arrowhead=""];
TestSpec->Group1->Group3->TestCase;
Product->TestPlan->TestCase;
Keyword->TestCase [arrowtail="crow"];
Product->RequirementSpecification->Requirement;
Requirement->TestCase[arrowtail="crow"];
TestPlan->Build;
TestCase->TestLog;
Build->TestLog;
TestLog->Bug;
TestPlan->Keyword;
}
</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), то появляется этот отчет, показывающий сводную информацию о зарегистрированных багах:

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

== Отчет о выполнении требований ==
Данный отчет для каждой спецификации требований показывает статус требований, на основе данных о результатах выполнения тестов связанных с ними.
Возможны следующие статусы требований:
; Требование выполнено: это означает что все тесты связанные с данным требование выполнены на активной (выбранной с менб справа) сборке выполнены успешно.
: Требование нарушено: есть тесты связанные с требованием и выполненые с результатом «провален».
: Требование заблокировано: есть тесты связанные с требованием и выполненые с результатом «блокирован».
: Требование непроверено: либо нет тестов с вязанных с требование либо все они в статусе «не выполнен».

TestLink

2007-10-05T13:10:03Z

Andrew: /* Основные понятия */

[[Category:TestLink]]

[[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="Тэг (ключевое слово)"];
Build [label="Сборка"];
TestLog [label="Результат теста"];
Bug [label="Отчет об ошибке" fillcolor="green"];

Product->TestSpec [arrowhead=""];
TestSpec->Group1->Group2->Group3->TestCase;
Product->TestPlan->TestCase;
Keyword->TestCase [arrowtail="crow"];
Product->RequirementSpecification->Requirement;
Requirement->TestCase[arrowtail="crow"];
TestPlan->Build;
TestCase->TestLog;
Build->TestLog;
TestLog->Bug;
}
</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), то появляется этот отчет, показывающий сводную информацию о зарегистрированных багах:

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

== Отчет о выполнении требований ==
Данный отчет для каждой спецификации требований показывает статус требований, на основе данных о результатах выполнения тестов связанных с ними.
Возможны следующие статусы требований:
; Требование выполнено: это означает что все тесты связанные с данным требование выполнены на активной (выбранной с менб справа) сборке выполнены успешно.
: Требование нарушено: есть тесты связанные с требованием и выполненые с результатом «провален».
: Требование заблокировано: есть тесты связанные с требованием и выполненые с результатом «блокирован».
: Требование непроверено: либо нет тестов с вязанных с требование либо все они в статусе «не выполнен».

TestLink

2007-10-05T13:08:47Z

Andrew: /* Основные понятия */

[[Category:TestLink]]

[[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="Тэг (ключевое слово)"];
Build [label="Сборка"];
TestLog [label="Результат теста"];

Product->TestSpec [arrowhead=""];
TestSpec->Group1->Group2->Group3->TestCase;
Product->TestPlan->TestCase;
Keyword->TestCase [arrowtail="crow"];
Product->RequirementSpecification->Requirement;
Requirement->TestCase[arrowtail="crow"];
TestPlan->Build;
TestCase->TestLog;
Build->TestLog;
}
</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), то появляется этот отчет, показывающий сводную информацию о зарегистрированных багах:

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

== Отчет о выполнении требований ==
Данный отчет для каждой спецификации требований показывает статус требований, на основе данных о результатах выполнения тестов связанных с ними.
Возможны следующие статусы требований:
; Требование выполнено: это означает что все тесты связанные с данным требование выполнены на активной (выбранной с менб справа) сборке выполнены успешно.
: Требование нарушено: есть тесты связанные с требованием и выполненые с результатом «провален».
: Требование заблокировано: есть тесты связанные с требованием и выполненые с результатом «блокирован».
: Требование непроверено: либо нет тестов с вязанных с требование либо все они в статусе «не выполнен».

TestLink

2007-10-05T12:56:01Z

Andrew: /* Основные понятия */

[[Category:TestLink]]

[[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), то появляется этот отчет, показывающий сводную информацию о зарегистрированных багах:

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

== Отчет о выполнении требований ==
Данный отчет для каждой спецификации требований показывает статус требований, на основе данных о результатах выполнения тестов связанных с ними.
Возможны следующие статусы требований:
; Требование выполнено: это означает что все тесты связанные с данным требование выполнены на активной (выбранной с менб справа) сборке выполнены успешно.
: Требование нарушено: есть тесты связанные с требованием и выполненые с результатом «провален».
: Требование заблокировано: есть тесты связанные с требованием и выполненые с результатом «блокирован».
: Требование непроверено: либо нет тестов с вязанных с требование либо все они в статусе «не выполнен».

TestLink

2007-09-20T14:19:22Z

Andrew: /* Основные понятия */

[[Category:TestLink]]

[[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="Проект"];
Group1 [label="Группа тестов"];
Group2 [label="..."];
Group3 [label="Группа тестов"];
TestCase [label="Тест кейс"];
TestPlan [label="План тестирования"];
RequirementSpecification [label="Спецификация требований"];
Requirement [label="Требование"];
Keyword [label="Тэг (ключевое слово)"];

Product->Group1->Group2->Group3->TestCase;
Product->TestPlan->TestCase;
Keyword->TestCase [arrowtail="crow"];
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), то появляется этот отчет, показывающий сводную информацию о зарегистрированных багах:

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

== Отчет о выполнении требований ==
Данный отчет для каждой спецификации требований показывает статус требований, на основе данных о результатах выполнения тестов связанных с ними.
Возможны следующие статусы требований:
; Требование выполнено: это означает что все тесты связанные с данным требование выполнены на активной (выбранной с менб справа) сборке выполнены успешно.
: Требование нарушено: есть тесты связанные с требованием и выполненые с результатом «провален».
: Требование заблокировано: есть тесты связанные с требованием и выполненые с результатом «блокирован».
: Требование непроверено: либо нет тестов с вязанных с требование либо все они в статусе «не выполнен».

TestLink

2007-09-17T14:23:53Z

Andrew: /* Иерархия групп тестов */

[[Category:TestLink]]

[[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="Продукт/Проект"];
Group1 [label="Группа тестов"];
Group2 [label="..."];
Group3 [label="Группа тестов"];
TestCase [label="Тест кейс"];
TestPlan [label="План тестирования"];
RequirementSpecification [label="Спецификация требований"];
Requirement [label="Требование"];
Keyword [label="Тэг (ключевое слово)"];

Product->Group1->Group2->Group3->TestCase;
Product->TestPlan->TestCase;
Keyword->TestCase [arrowtail="crow"];
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), то появляется этот отчет, показывающий сводную информацию о зарегистрированных багах:

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

== Отчет о выполнении требований ==
Данный отчет для каждой спецификации требований показывает статус требований, на основе данных о результатах выполнения тестов связанных с ними.
Возможны следующие статусы требований:
; Требование выполнено: это означает что все тесты связанные с данным требование выполнены на активной (выбранной с менб справа) сборке выполнены успешно.
: Требование нарушено: есть тесты связанные с требованием и выполненые с результатом «провален».
: Требование заблокировано: есть тесты связанные с требованием и выполненые с результатом «блокирован».
: Требование непроверено: либо нет тестов с вязанных с требование либо все они в статусе «не выполнен».

TestLink

2007-09-17T14:04:34Z

Andrew: /* Общая информация */

[[Category:TestLink]]

[[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="Продукт/Проект"];
Group1 [label="Группа тестов"];
Group2 [label="..."];
Group3 [label="Группа тестов"];
TestCase [label="Тест кейс"];
TestPlan [label="План тестирования"];
RequirementSpecification [label="Спецификация требований"];
Requirement [label="Требование"];
Keyword [label="Тэг (ключевое слово)"];

Product->Group1->Group2->Group3->TestCase;
Product->TestPlan->TestCase;
Keyword->TestCase [arrowtail="crow"];
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». Например, если тест «1» был успешно пройден в сборке «2», он будет раскрашен в зеленый цвет.

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

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

=== Ввод результатов тестов ===
Страница результатов тестирования показывается справа при выборе в навигационной панели некоторого теста или группы тестов.
На этой странице изображены:
* Заметки по плану тестирования;
* Описание сборки;
* Панель массового управления состоянием тестов;
: служит для массового присвоения одинаковых результатов выполнения всем тестам в наборе(группе)
* История выполнения теста или результаты последнего выполнения;
* Описание теста:
** резюме;
** шаги выполнения;
** ожидаемые результаты.
* Настраиваемые поля;
* Поле для заметок;
* Радиокнопка для выбора результата теста.

Посде того как вы ввели результат выполнения теста, заполнили все пользовательские поля, если это необходимо, и заметки, можно ввести привязку результатов к описанию ошибки (багу) в системе управления ошибками (''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), то появляется этот отчет, показывающий сводную информацию о зарегистрированных багах:

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

== Отчет о выполнении требований ==
Данный отчет для каждой спецификации требований показывает статус требований, на основе данных о результатах выполнения тестов связанных с ними.
Возможны следующие статусы требований:
; Требование выполнено: это означает что все тесты связанные с данным требование выполнены на активной (выбранной с менб справа) сборке выполнены успешно.
: Требование нарушено: есть тесты связанные с требованием и выполненые с результатом «провален».
: Требование заблокировано: есть тесты связанные с требованием и выполненые с результатом «блокирован».
: Требование непроверено: либо нет тестов с вязанных с требование либо все они в статусе «не выполнен».

TestLink

2007-09-17T13:39:19Z

Andrew: /* Создание тестов */

[[Category:TestLink]]

[[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="Продукт/Проект"];
Group1 [label="Группа тестов"];
Group2 [label="..."];
Group3 [label="Группа тестов"];
TestCase [label="Тест кейс"];
TestPlan [label="План тестирования"];
RequirementSpecification [label="Спецификация требований"];
Requirement [label="Требование"];
Keyword [label="Тэг (ключевое слово)"];

Product->Group1->Group2->Group3->TestCase;
Product->TestPlan->TestCase;
Keyword->TestCase [arrowtail="crow"];
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». Например, если тест «1» был успешно пройден в сборке «2», он будет раскрашен в зеленый цвет.

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

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

=== Ввод результатов тестов ===
Страница результатов тестирования показывается справа при выборе в навигационной панели некоторого теста или группы тестов.
На этой странице изображены:
* Заметки по плану тестирования;
* Описание сборки;
* Панель массового управления состоянием тестов;
: служит для массового присвоения одинаковых результатов выполнения всем тестам в наборе(группе)
* История выполнения теста или результаты последнего выполнения;
* Описание теста:
** резюме;
** шаги выполнения;
** ожидаемые результаты.
* Настраиваемые поля;
* Поле для заметок;
* Радиокнопка для выбора результата теста.

Посде того как вы ввели результат выполнения теста, заполнили все пользовательские поля, если это необходимо, и заметки, можно ввести привязку результатов к описанию ошибки (багу) в системе управления ошибками (''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), то появляется этот отчет, показывающий сводную информацию о зарегистрированных багах:

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

== Отчет о выполнении требований ==
Данный отчет для каждой спецификации требований показывает статус требований, на основе данных о результатах выполнения тестов связанных с ними.
Возможны следующие статусы требований:
; Требование выполнено: это означает что все тесты связанные с данным требование выполнены на активной (выбранной с менб справа) сборке выполнены успешно.
: Требование нарушено: есть тесты связанные с требованием и выполненые с результатом «провален».
: Требование заблокировано: есть тесты связанные с требованием и выполненые с результатом «блокирован».
: Требование непроверено: либо нет тестов с вязанных с требование либо все они в статусе «не выполнен».

TestLink

2007-09-17T13:36:39Z

Andrew: /* Создание тестов */

[[Category:TestLink]]

[[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="Продукт/Проект"];
Group1 [label="Группа тестов"];
Group2 [label="..."];
Group3 [label="Группа тестов"];
TestCase [label="Тест кейс"];
TestPlan [label="План тестирования"];
RequirementSpecification [label="Спецификация требований"];
Requirement [label="Требование"];
Keyword [label="Тэг (ключевое слово)"];

Product->Group1->Group2->Group3->TestCase;
Product->TestPlan->TestCase;
Keyword->TestCase [arrowtail="crow"];
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». Например, если тест «1» был успешно пройден в сборке «2», он будет раскрашен в зеленый цвет.

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

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

=== Ввод результатов тестов ===
Страница результатов тестирования показывается справа при выборе в навигационной панели некоторого теста или группы тестов.
На этой странице изображены:
* Заметки по плану тестирования;
* Описание сборки;
* Панель массового управления состоянием тестов;
: служит для массового присвоения одинаковых результатов выполнения всем тестам в наборе(группе)
* История выполнения теста или результаты последнего выполнения;
* Описание теста:
** резюме;
** шаги выполнения;
** ожидаемые результаты.
* Настраиваемые поля;
* Поле для заметок;
* Радиокнопка для выбора результата теста.

Посде того как вы ввели результат выполнения теста, заполнили все пользовательские поля, если это необходимо, и заметки, можно ввести привязку результатов к описанию ошибки (багу) в системе управления ошибками (''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), то появляется этот отчет, показывающий сводную информацию о зарегистрированных багах:

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

== Отчет о выполнении требований ==
Данный отчет для каждой спецификации требований показывает статус требований, на основе данных о результатах выполнения тестов связанных с ними.
Возможны следующие статусы требований:
; Требование выполнено: это означает что все тесты связанные с данным требование выполнены на активной (выбранной с менб справа) сборке выполнены успешно.
: Требование нарушено: есть тесты связанные с требованием и выполненые с результатом «провален».
: Требование заблокировано: есть тесты связанные с требованием и выполненые с результатом «блокирован».
: Требование непроверено: либо нет тестов с вязанных с требование либо все они в статусе «не выполнен».

TestLink

2007-09-17T13:27:34Z

Andrew: Схема

[[Category:TestLink]]

[[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="Продукт/Проект"];
Group1 [label="Группа тестов"];
Group2 [label="..."];
Group3 [label="Группа тестов"];
TestCase [label="Тест кейс"];
TestPlan [label="План тестирования"];
RequirementSpecification [label="Спецификация требований"];
Requirement [label="Требование"];
Keyword [label="Тэг (ключевое слово)"];

Product->Group1->Group2->Group3->TestCase;
Product->TestPlan->TestCase;
Keyword->TestCase [arrowtail="crow"];
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». Например, если тест «1» был успешно пройден в сборке «2», он будет раскрашен в зеленый цвет.

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

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

=== Ввод результатов тестов ===
Страница результатов тестирования показывается справа при выборе в навигационной панели некоторого теста или группы тестов.
На этой странице изображены:
* Заметки по плану тестирования;
* Описание сборки;
* Панель массового управления состоянием тестов;
: служит для массового присвоения одинаковых результатов выполнения всем тестам в наборе(группе)
* История выполнения теста или результаты последнего выполнения;
* Описание теста:
** резюме;
** шаги выполнения;
** ожидаемые результаты.
* Настраиваемые поля;
* Поле для заметок;
* Радиокнопка для выбора результата теста.

Посде того как вы ввели результат выполнения теста, заполнили все пользовательские поля, если это необходимо, и заметки, можно ввести привязку результатов к описанию ошибки (багу) в системе управления ошибками (''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), то появляется этот отчет, показывающий сводную информацию о зарегистрированных багах:

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

== Отчет о выполнении требований ==
Данный отчет для каждой спецификации требований показывает статус требований, на основе данных о результатах выполнения тестов связанных с ними.
Возможны следующие статусы требований:
; Требование выполнено: это означает что все тесты связанные с данным требование выполнены на активной (выбранной с менб справа) сборке выполнены успешно.
: Требование нарушено: есть тесты связанные с требованием и выполненые с результатом «провален».
: Требование заблокировано: есть тесты связанные с требованием и выполненые с результатом «блокирован».
: Требование непроверено: либо нет тестов с вязанных с требование либо все они в статусе «не выполнен».

Strings.txt (TestLink-RU)

2007-08-30T08:35:20Z

Andrew: Сменил "Тест" на "тест"

[[Category:TestLink]]

Статьяz с основной локализацией интерфейса. Статья разбита по разделам, в соответствии с разделами в оригинальном файле <tt>strings.txt</tt>. По ссылке «[[#Скачать|скачать]]» можно получить готовый PHP-файл, который нужно разместить в каталоге
testlink\locale\ru_RU\strings.txt

=Скачать=
[{{SERVER}}{{localurl:Special:CisGetPHPPage|pagetitle={{PAGENAMEE}}}} Получить PHP-код]

= Оригинал (наиболее полный английский перевод) =
* http://testlink.cvs.sourceforge.net/testlink/testlink/locale/en_GB/

=Разделы файла strings.txt (ru_RU)=
<code-php>
/**
* TestLink Open Source Project - http://testlink.sourceforge.net/
*
* Filename $RCSfile: strings.txt,v $
*
* @version $Revision$
* @modified $Date$ $Author$
*
* @author Vadim Ivanchenko, Stas Fomin, and russian Testlink community.
* http://lib.custis.ru/index.php/TestLink:_strings.txt_%28RU%29
*
*
**/

$TLS_STRINGFILE_CHARSET = "UTF-8";
</code-php>

==General==
<code-php>
$TLS_asc = "по возрастанию";
$TLS_btn_no = "Нет";
$TLS_create = "Создать";
$TLS_desc = "по убыванию";
$TLS_test_case = "Тест";
$TLS_testcase = $TLS_test_case;
$TLS_test_plan = "План тестирования";
$TLS_testplan = $TLS_test_plan;
$TLS_test_suite = "Группа тестов";
$TLS_SRS = "SRS";
$TLS_Role = "Роль";
$TLS_Keyword = "Ключевое слово";
$TLS_Milestone = "Веха";
$TLS_testsuite_created = "Группа тестов создана";
$TLS_requirement = "Требование";
$TLS_assigned = "назначен";
$TLS_unassigned = "свободен";
$TLS_import_file_type = "Тип импортируемого файла";
$TLS_max_file_size_is = "Макс. размер файла";
$TLS_supported_file_formats = "Поддерживаемые форматы файлов";
</code-php>

==firstLogin.php==
<code-php>
$TLS_cant_create_user = "К сожалению, не удалось создать ваш логин. Пожалуйста, свяжитесь с администратором!";
$TLS_empty_email_address = " Пожалуйста, укажите e-mail!";
$TLS_empty_first_name = " Пожалуйста, укажите имя пользователя.";
$TLS_empty_last_name = " Пожалуйста, укажите фамилию.";
$TLS_fatal_page_title = "TestLink ::: Fatal Error";
$TLS_invalid_user_name = "Некорректный логин пользователя. Пожалуйста, придумайте другой.";
$TLS_passwd_dont_match = "Два введенных пароля не совпадают. Учтите, что пароли чувствительны к регистру, и попробуйте ещё раз.";
$TLS_user_cant_be_created_because = "Не удалось создать ваш аккаунт. Причина:";
$TLS_user_name_exists = "Этот логин пользователя уже используется. Пожалуйста, выберите другой.";
$TLS_valid_user_name_format = "Логин пользователя может состоять только из алфавитно-цифровых символов, пробелов, дефисов и подчеркиваний.";
$TLS_warning_empty_pwd = "Пожалуйста, укажите пароль. Пароль не может быть пустым.";
$TLS_your_info_please = "Введите информацию о пользователе";
</code-php>

==index.php==
<code-php>
$TLS_main_page_title = "TestLink::Главная страница";
</code-php>

==keywordsimport.php==
<code-php>
$TLS_please_choose_keywords_file = "Пожалуйста, выберите файл для загрузки";
$TLS_keywords_file = "Файл с ключевыми словами";
</code-php>

==lostPassword.php==
<code-php>
$TLS_bad_user = "Пользователь не найден, попробуйте еще";
$TLS_contact_admin = "<br> Если проблемы будут продолжаться, пожалуйста, свяжитесь с администратором системы.";
$TLS_mail_empty_address = "Вы не указали email-адреса в вашем профиле! Теперь, чтобы сбросить пароль вам нужно связаться с администратором TestLink-системы.";
$TLS_mail_passwd_subject = "Ваш новый пароль к TestLink'у.";
$TLS_mail_problems = "Ошибка в почтовых настройках, пожалуйста, свяжитесь с администратором.";
$TLS_page_title_lost_passwd = "TestLink - Утерян пароль";
$TLS_your_info_for_passwd = "Заполните информацию о вашем пользователе, и пароль будет вам выслан по почте.";
$TLS_your_password_is = "Ваш пароль к TestLink'у: <br>";
</code-php>

==login.php==
<code-php>
$TLS_bad_user_passwd = "Логин или пароль неверен. Попробуйте ещё!";
$TLS_login_msg_session_exists1 = "Ваша сессия в этом броузере ещё активна. Пожалуйста, используйте ";
$TLS_login_msg_session_exists2 = " если вы хотите обновить вашу сессию.";
$TLS_logout_link = "Выход";
$TLS_passwd_lost = "Ваш пароль выслан вам по email на адрес, который вы указали при регистрации. Проверьте вашу почту. В случае проблем, обратитесь к администратору вашего TestLink'а.";
$TLS_password_reseted="Новый пароль выслан вам по почте";
$TLS_please_login = "Пожалуйста, войдите в систему...";
$TLS_session_expired = "Время ваша сессии окончилось. Пожалуйста, войдите в систему заново.";
$TLS_your_first_login = "Добро пожаловать в TestLink! Сейчас у вас только гостевой доступ. Для большего, нужно войти в систему.";
</code-php>

==planPriority.php==
<code-php>
$TLS_high_priority = "Высокий";
$TLS_low_priority = "Низкий";
$TLS_medium_priority = "Средний";

$TLS_high_risk = "Высокий";
$TLS_low_risk = "Низкий";
$TLS_medium_risk = "Средний";

$TLS_high_importance = "Высокая";
$TLS_low_importance = "Низкая";
$TLS_medium_importance= "Средняя";
</code-php>

==tcEdit.php==
<code-php>
$TLS_tc_created = "Тест %s успешно создан";
$TLS_tc_deleted = "Тест %s успешно удален";
$TLS_tc_updated = "Тест %s отредактирован успешно";
$TLS_tc_update_failed = "Не удалась правка теста %s!";
</code-php>

==gui/templates/attachment404.tpl==
<code-php>
$TLS_btn_close = "Закрыть";
$TLS_error_attachment_not_found = "Ошибка: Вложение не найдено!";
$TLS_title_downloading_attachment = "Загружаем вложение";
</code-php>

==gui/templates/attachmentdelete.tpl==
<code-php>
$TLS_deleting_was_ok = "Вложение удалено.";
$TLS_error_attachment_delete = "При удалении вложения произошла ошибка!";
$TLS_title_delete_attachment = "Удалить вложение";
</code-php>

==gui/templates/containerDelete.tpl==
<code-php>
$TLS_btn_yes_del_comp = "Да, удалить группу тестов";
$TLS_container_title_testsuite =$TLS_test_suite;
$TLS_linked_but_not_executed="Связан с одним или более планом тестирования, но не выполнялась";
$TLS_question_del = "Действительно удалить";
$TLS_th_link_exec_status = "Статус исполнения и связей";
</code-php>

==gui/templates/containerNew.tpl==
<code-php>
$TLS_btn_create_testsuite = "Создать группу тестов";
$TLS_tc_keywords = "Ключевые слова";
$TLS_title_create = "Создать";
$TLS_warning_empty_testsuite_name = "Пожалуйста, задайте имя для группы тестов";
</code-php>

==gui/templates/bug_add.tpl==
<code-php>
$TLS_btn_add_bug = "Добавить баг";
$TLS_bug_id = "Bug id";
$TLS_button_enter_bug = "Создать новый баг";
$TLS_title_bug_add = "Добавить баг";
$TLS_link_bts_create_bug = "Доступ к системе регистрации багов";
</code-php>

==gui/templates/bug_delete.tpl==
<code-php>
$TLS_title_delete_bug = "Удалить баг";
</code-php>

==gui/templates/containerMove.tpl==
<code-php>
$TLS_btn_cp = "Копировать";
$TLS_btn_move = "Переместить";
$TLS_choose_target = "Выберите куда";
$TLS_cont_move_first = "Переместить это";
$TLS_cont_move_second = "в другое";
$TLS_copy_keywords = "Копировать ключевые слова";
$TLS_defined_exclam = "определен !";
$TLS_include_nested = "Включая вложенные данные (только для копирования).";
$TLS_sorry_further = "К сожалению, больше ничего нет ";
$TLS_title_move_cp = "Переместить/Скопировать";
</code-php>

==gui/templates/reqCreate.tpl==
<code-php>
$TLS_btn_cancel = "Отменить";
$TLS_btn_create = "Создать";
$TLS_help = "Помощь";
$TLS_req_create = "Создать требование";
$TLS_req_doc_id = "DOC-ID";
$TLS_req_spec = "Спецификация требований";
$TLS_reqs = "Требования";
$TLS_scope = "Описание";
$TLS_status = "Состояние";
$TLS_title = "Заголовок";
$TLS_warning_empty_req_title = "Заголовок требования должен быть не пуст!";
$TLS_warning_empty_reqdoc_id = "ID документа-требования не должен быть пуст!";
</code-php>

==gui/templates/containerOrder.tpl==
<code-php>
$TLS_btn_upd = "Обновить";
$TLS_no_nodes_to_reorder = "К сожалению, тут нечего упорядочивать.";
$TLS_node = "Имя";
$TLS_th_id = "ID";
$TLS_th_node_type = "Тест / Группа тестов";
$TLS_th_order = "Порядок";
$TLS_title_change_node_order = "Изменить порядок 'потомков'";
$TLS_node_type_dbtable_testsuites=$TLS_test_suite;
$TLS_node_type_dbtable_testcases=$TLS_testcase;
</code-php>

==gui/templates/containerView.tpl==
<code-php>
$TLS_alt_del_com = "Удалить эту группу тестов";
$TLS_alt_edit_com = "Править дату и заголовок для этой группы тестов";
$TLS_alt_move_cp_com = "Переместить или скопировать эту группу тестов в другой проект";
$TLS_btn_del_com = "Удалить";
$TLS_btn_edit_com = "Править";
$TLS_btn_export_all_testsuites = "Экспортировать все группы тестов";
$TLS_btn_export_tc = "Экспортировать тест(ы)";
$TLS_btn_export_testsuite = "Экспортировать группу тестов";
$TLS_btn_import_tc = "Импортировать тест(ы)";
$TLS_btn_import_testsuite = "Импортировать группу тестов";
$TLS_btn_move_cp_com = "Переместить/Копировать";
$TLS_btn_new_cat = "Новая группа тестов";
$TLS_btn_new_com = "Новая группа тестов";
$TLS_btn_new_tc = "Создать тест(ы)";
$TLS_btn_reorder_cat = "Переупорядочить потомков";
$TLS_edit_testproject_basic_data = "Править основные данные проекта";
$TLS_th_notes = "Описание";
$TLS_th_product_name = "Имя проекта";
</code-php>

==gui/templates/cfields_edit.tpl==
<code-php>
$TLS_available_on = "Доступно для";
$TLS_btn_add = "Добавить";
$TLS_btn_delete = "Удалить";
$TLS_btn_ok = "Ok";
$TLS_custom_field = "Пользовательское поле";
$TLS_enable_on_design = "Разрешить при <br>спецификации теста";
$TLS_enable_on_exec = "Разрешить при <br>прогоне теста";
$TLS_label = "Метка";
$TLS_name = "Имя";
$TLS_popup_delete_custom_field = "Вы уверены, что хотите удалить пользовательское поле?";
$TLS_possible_values = "Возможные значения";
$TLS_show_on_design = "Показывать при <br>спецификации теста";
$TLS_show_on_exec = "Показывать при <br>прогоне теста";
$TLS_testcase = $TLS_test_case;
$TLS_title_cfields_mgmt = "Пользовательские поля";
$TLS_type = "Тип";
$TLS_warning_empty_cfield_label = "Пожалуйста, введите метку для этого пользовательского поля.";
$TLS_warning_empty_cfield_name = "Пожалуйста, введите имя этого пользовательского поля.";
</code-php>

==gui/templates/inc_update.tpl==
<code-php>
$TLS_info_failed_db_upd = "Не удалось обновить базу данных!";
$TLS_info_failed_db_upd_details = "Не удалось обновить базу данных! - Подробности:";
$TLS_invalid_query = "Ошибка:";
$TLS_warning = "Предупреждение!!";
$TLS_was_success = " был(и) успешно ";
</code-php>

==gui/templates/execNavigator.tpl==
<code-php>
$TLS_TestPlan = "План тестирования";
$TLS_btn_apply_filter = "Применить фильтр";
$TLS_btn_update_menu = "Обновить меню";
$TLS_caption_nav_filter_settings = "Параметры выборки";
$TLS_current_build = "Текущая сборка";
$TLS_filter_owner = "Ответственный";
$TLS_filter_result = "Результат";
$TLS_filter_tcID = "Фильтр: ID теста";
$TLS_keyword = "Ключевое слово";
$TLS_test_status_all_status="Все";
</code-php>

==gui/templates/mainPage.tpl==
<code-php>
$TLS_th_my_perc_completed = "У меня выполнено [%]";
$TLS_th_name = "Имя";
$TLS_th_perc_completed = "Выполнено [%]";
$TLS_title_your_tp_metrics = "Ваши метрики для плана тестирования";
</code-php>

==gui/templates/newest_tcversions.tpl==
<code-php>
$TLS_linked_version = "Связанная версия";
$TLS_newest_version = "Самая новая из доступных активных версий";
$TLS_title_newest_tcversions = "Самые новые версии связанных тестов";
</code-php>

==gui/templates/emailSent.tpl==
<code-php>
$TLS_send_test_report = "- Послать тест-отчёт";
</code-php>

==gui/templates/reqImport.tpl==
<code-php>
$TLS_Result = "Результат";
$TLS_Title = "Заголовок";
$TLS_btn_back2srs = "Назад, к спецификации требований";
$TLS_btn_import = "Импорт";
$TLS_btn_upload_file = "Загрузить файл";
$TLS_check_req_file_structure = "Пожалуйста, проверьте формат файла. Не получается получить из этого файла требования";
$TLS_local_file = "Файл:";
$TLS_max_size_cvs_file1 = "Максимальный размер для этого файла";
$TLS_max_size_cvs_file2 = "kB";
$TLS_req_import_check_note = "Пожалуйста, разрешите возможные конфликты и запустите процесс импорта.";
$TLS_req_import_dont_empty = "Не импортируйте элементы с пустой Сферой";
$TLS_req_import_option_double = "Добавить ещё с тем же заголовком";
$TLS_req_import_option_header = "Разрешить конфликт";
$TLS_req_import_option_overwrite = "Обновить существующий";
$TLS_req_import_option_skip = "Пропускать импорт дублирующих требований";
$TLS_req_import_type = "Тип:";
$TLS_req_msg_norequirement = "Нет требований";
$TLS_required_cvs_format = "Формат файла с требованиями:";
$TLS_title_choose_file_type = "Выберите тип файла";
$TLS_title_choose_local_file = "Выберите файл для загрузки";
$TLS_title_req_import = "Загрузка требований";
$TLS_title_req_import_check_input = "Проверьте импортируемые данные";
</code-php>

==gui/templates/inc_attachments.tpl==
<code-php>
$TLS_alt_delete_build = "Удалить эту сборку";
$TLS_alt_delete_attachment = "Удалить это вложение";
$TLS_attached_files = "Вложенные файлы";
$TLS_attachment_feature_disabled = "вложения отключены";
$TLS_button_upload = "Загрузить";
$TLS_upload_file_new_file = "Загрузить новый файл";
$TLS_warning_delete_attachment = "Действительно удалить вложение?";
</code-php>

==gui/templates/resultsNavigator.tpl==
<code-php>
$TLS_btn_print = "Печать";
$TLS_note_email_sent_t = "Примечание: email format послан на email пользователя";
$TLS_send_results = "Послать отчеты";
$TLS_send_to = "To:";
$TLS_subject = "Subject:";
$TLS_title_active_build = "Активная сборка";
$TLS_title_report_type = "Формат отчета";
$TLS_via_email = "через eMail";
</code-php>

==gui/templates/inc_attachments_upload.tpl==

==gui/templates/cfields_view.tpl==
<code-php>
$TLS_btn_cfields_create = "Создать";
$TLS_manage_cfield = "Управлять пользовательскими полями";
</code-php>

==gui/templates/inc_cat_viewer_ro_m0.tpl==
<code-php>
$TLS_cat_scope = "Описание";
$TLS_category = "Группа тестов";
$TLS_configuration = "Конфигурация";
$TLS_data = "Данные";
$TLS_not_defined = "Не определено.";
$TLS_tools = "Инструменты";
</code-php>

==gui/templates/inc_cat_viewer_rw.tpl==
<code-php>
$TLS_cat_alt_name = "Обязательно заполнить имя группы тестов.";
$TLS_cat_config = "Конфигурация";
$TLS_cat_data = "Данные";
$TLS_cat_name = "Имя группы тестов";
$TLS_cat_tools = "Инструменты";
</code-php>

==gui/templates/reqEdit.tpl==
<code-php>
$TLS_btn_update = "Обновить";
$TLS_by = "by";
$TLS_coverage = "Покрытие";
$TLS_popup_delete_req = "Удалить это требование, Вы уверены?";
$TLS_req_edit = "Править требование";
$TLS_req_msg_notestcase = "Связанных тестов нет.";
$TLS_requirement_spec = "Спецификация требования";
$TLS_test_case_id = "ID";
$TLS_title_created = "Создано:";
$TLS_title_last_mod = "Последняя правка:";
</code-php>

==gui/templates/buildNew.tpl==
<code-php>
$TLS_active = "Активная";
$TLS_enter_build = "Заголовок";
$TLS_enter_build_notes = "Описание";
$TLS_msg_build = "Замечание: Каждая сборка относится к активному плану тестирования. Описание должно включать: список развертываемых пакетов, утверждений, состояние, и т.п.";
$TLS_open = "Открыть";
$TLS_test_plan = "План тестирования";
$TLS_title_build_2 = "Управление сборками";
$TLS_title_build_create = "Создать новую Сборку";
$TLS_title_build_update = "Править Сборку";
$TLS_warning_empty_build_name = "Пожалуйста, введите имя для этой Сборки!";
</code-php>

==gui/templates/inc_comp_viewer_ro.tpl==
<code-php>
$TLS_component = "Группа тестов";
$TLS_introduction = "Введение";
$TLS_limitations = "Ограничения";
$TLS_methodology = "Методология";
$TLS_references = "Ссылки";
</code-php>

==gui/templates/inc_comp_viewer_rw.tpl==
<code-php>
$TLS_comp_alt_name = "Обязательно введите имя группы тестов.";
$TLS_comp_intro = "Введение";
$TLS_comp_lim = "Ограничения";
$TLS_comp_method = "Методология";
$TLS_comp_name = "Имя группы тестов";
$TLS_comp_ref = "Ссылки";
$TLS_comp_scope = "Описание";
</code-php>

==gui/templates/reqSpecView.tpl==
<code-php>
$TLS_btn_analyse = "Анализировать";
$TLS_btn_check_all = "Проверить все";
$TLS_btn_delete_spec = "Удалить спецификацию";
$TLS_btn_edit_spec = "Править спецификацию";
$TLS_btn_export_reqs = "Экспортировать требования";
$TLS_btn_req_create = "Создать новое требование";
$TLS_btn_spec_list = "Список спецификаций";
$TLS_btn_uncheck_all = "Убрать все отметки";
$TLS_cant_delete_req_nothing_sel = "Пожалуйста, выберите требование!";
$TLS_popup_sure_delete = "Вы уверены удалить эту спецификацию требования?";
$TLS_req_select_create_tc = "Создать тесты";
$TLS_req_select_delete = "Удалить требования";
$TLS_req_title_list = "Список требований";
$TLS_req_total = "Всего треб.";
$TLS_req_reorder = "Переупорядочить требования?";
$TLS_warning_delete_requirements = "Вы уверены удалить выбранные требования?";
$TLS_title_change_req_order = "Переупорядочивание требований";
</code-php>

==gui/templates/inc_copyrightnotice.tpl==
<code-php>
$TLS_gnu_gpl = "GNU GPL";
$TLS_lic_home = "Домой";
$TLS_lic_product = "TestLink project";
$TLS_licensed_under = "TestLink лицензируется согласно ";
</code-php>

==gui/templates/containerEdit.tpl==
<code-php>
$TLS_btn_update_testsuite = "Обновить группу тестов";
$TLS_title_edit_level = "Править";
</code-php>

==gui/templates/reqSpecAnalyse.tpl==
<code-php>
$TLS_edit = "Править";
$TLS_none = "Пусто ";
$TLS_req = "Требования";
$TLS_req_spec_change = "Изменить спецификацию требований на ";
$TLS_req_title_analyse = "Анализировать спецификацию требований ";
$TLS_req_title_covered = "Покрытые требования";
$TLS_req_title_in_tl = "Требований, зарегистрированных в TestLink";
$TLS_req_title_nottestable = "Нетестируемые требования";
$TLS_req_title_uncovered = "Непокрытые требования";
$TLS_req_title_not_in_tl = "Требований, отсутствующих в TestLink";
$TLS_req_total_count = "Всего требований";
$TLS_testcases = "Тесты";
</code-php>

==gui/templates/reqSpecCreate.tpl==
<code-php>
$TLS_action_create_srs = "Создать спецификацию требований";
$TLS_testproject = "проект";
</code-php>

==gui/templates/inc_reqView.tpl==
<code-php>
$TLS_Author = "Автор";
$TLS_last_edit = "Последняя правка: ";
</code-php>

==gui/templates/inc_res_by_comp.tpl==
<code-php>
$TLS_title_res_by_top_level_suites = "Результаты топовых групп тестов";
$TLS_trep_blocked = "Блокировано";
$TLS_trep_comp = "Группа тестов";
$TLS_trep_comp_perc = "Выполнена [%]";
$TLS_trep_failed = "Сбой";
$TLS_trep_not_run = "Не запускали";
$TLS_trep_passed = "Выполнено";
$TLS_trep_total = "Всего";
</code-php>

==gui/templates/inc_res_by_keyw.tpl==
<code-php>
$TLS_title_res_by_kw = "Результаты по ключевому слову";
$TLS_trep_kw = "Ключевое слово";
</code-php>

==gui/templates/inc_res_by_owner.tpl==
<code-php>
$TLS_title_res_by_owner = "Результаты по тестировщику";
$TLS_trep_owner = "Тестировщик";
$TLS_title_res_by_tester = "Результаты по тестировщику";
$TLS_trep_tester = "Тестировщик";
</code-php>

==gui/templates/inc_res_by_prio.tpl==
<code-php>
$TLS_tit_end_date = "Дата окончания";
$TLS_tit_milestone = "Веха";
$TLS_title_res_by_prio = "Результаты по приоритету";
$TLS_trep_milestone_goal = "Цель вехи [%]";
$TLS_trep_prio = "Приоритет";
$TLS_trep_status = "Состояние";
</code-php>

==gui/templates/inc_res_by_ts.tpl==
<code-php>
$TLS_title_res_by_ts = "Результаты по группе тестов";
$TLS_trep_imp = "Важность";
$TLS_trep_risk = "Риск";
$TLS_trep_ts = "Группа тестов";
</code-php>

==gui/templates/reqSpecEdit.tpl==

==gui/templates/inc_show_bug_table.tpl==
<code-php>
$TLS_build = "Сборка";
$TLS_caption_bugtable = "Связанные баги";
$TLS_delete_bug="Удалить баг";
$TLS_del_bug_warning_msg = "Действительно удалить этот баг?";
</code-php>

==gui/templates/reqSpecList.tpl==
<code-php>
$TLS_btn_assign_tc = "Указать тест";
$TLS_no_docs = "Нет доступных документов.";
$TLS_req_list_docs = "Спецификации требований";
</code-php>

==gui/templates/tcEdit_New_viewer.tpl==
<code-php>
$TLS_alt_add_tc_name = "Обязательно укажите имя теста.";
$TLS_expected_results = "Ожидаемые результаты";
$TLS_steps = "Шаги";
$TLS_summary = "Резюме";
$TLS_tc_title = "Заголовок тест-кейса";
</code-php>

==gui/templates/show_exec_notes.tpl==
<code-php>
$TLS_title_execution_notes = "Замечания по выполнению";
</code-php>

==gui/templates/rolesedit.tpl==
<code-php>
$TLS_btn_create_role = "Создать";
$TLS_btn_edit_role = "Править";
$TLS_caption_define_role = "Определить роль";
$TLS_caption_possible_affected_users = "Возможно влияет на следующих пользователей";
$TLS_enter_role_notes = "Введите описание роли";
$TLS_menu_assign_product_roles = "Укажите роли проекта";
$TLS_menu_assign_testplan_roles = "Укажите роли для плана тестирования";
$TLS_menu_define_roles = "Новая роль";
$TLS_menu_mod_user = "Править пользователя";
$TLS_menu_new_user = "Новый пользователь";
$TLS_menu_edit_user = "Редактировать пользователя";
$TLS_menu_view_users = "Список пользователей";
$TLS_menu_view_roles = "Просмотр ролей";
$TLS_th_cf_rights = "Права на пользовательские поля";
$TLS_th_kw_rights = "Права на ключевые слова";
$TLS_th_mgttc_rights = "Права на управление тест-кейсами";
$TLS_th_product_rights = "Права на проект";
$TLS_th_req_rights = "Права на требование";
$TLS_th_rights = "Разрешения";
$TLS_th_rolename = "Роль";
$TLS_th_tp_rights = "Права на план тестирования";
$TLS_th_user_rights = "Права пользователей";
$TLS_title_user_mgmt = "Управление пользователями";
$TLS_warning_modify_role = "Действительно исправить роль?";
</code-php>

==gui/templates/tcSearchForm.tpl==
<code-php>
$TLS_btn_find = "Найти";
$TLS_caption_search_form = "Искать тесты";
$TLS_not_applied = "Не применимо";
$TLS_th_tcid = "ID теста";
$TLS_th_tcversion = "Версия";
$TLS_th_title = "Заголовок";
$TLS_title_search_tcs = "Поиск";
</code-php>

==gui/templates/infoWindow.tpl==

==gui/templates/tcDelete.tpl==
<code-php>
$TLS_btn_yes_iw2del = "Да, удалите тест!";
$TLS_question_del_tc = "Действительно удалить тест?";
$TLS_th_executed = "Выполнено";
$TLS_th_linked_to_tplan = "Связан с планом тестирования";
$TLS_th_version = "Версия";
</code-php>

==gui/templates/tcNew.tpl==
<code-php>
$TLS_title_new_tc = "Создать тест";
$TLS_warning_empty_tc_title = "Пожалуйста, задайте заголовок для теста";
</code-php>

==gui/templates/tcImport.tpl==
<code-php>
$TLS_title_imp_tc_data = "Импорт данных для теста";
</code-php>

==gui/templates/keywordsimport.tpl==
<code-php>
$TLS_title_keyword_import_to = "Импортировать ключевые слова в ";
$TLS_title_keyword_import = "Импорт ключевых слов";
</code-php>

==gui/templates/keywordsexport.tpl==
<code-php>
$TLS_btn_export = "Экспорт";
$TLS_title_req_import_to = "Импортировать требования в документ:";
</code-php>

==gui/templates/cfields_tproject_assign.tpl==
<code-php>
$TLS_btn_assign = "Привязать";
$TLS_btn_cfields_active_mgmt = "Обновить активное состояние";
$TLS_btn_cfields_display_order = "Сохранить порядок показа";
$TLS_btn_unassign = "Освободить от";
$TLS_cfields_active = "Активный";
$TLS_cfields_tproject_assign = "Привязать пользовательские поля";
$TLS_display_order = "Порядок показа";
$TLS_title_assigned_cfields = "Привязанные пользовательские поля";
$TLS_title_available_cfields = "Доступные пользовательские поля";
</code-php>

==gui/templates/usersview.tpl==
<code-php>
$TLS_No = "Нет";
$TLS_Yes = "Да";
$TLS_alt_delete_user = "Действительно удалить выбранного пользователя?";
$TLS_alt_edit_user = "Править пользователя";
$TLS_order_by_login = "По порядку логинов";
$TLS_order_by_role_descr = "По порядку описания ролей";
$TLS_th_active = "Активный";
$TLS_th_delete = "Удалить?";
$TLS_th_email = "Email";
$TLS_th_first_name = "Имя";
$TLS_th_last_name = "Фамилия";
$TLS_th_locale = "Локализация";
$TLS_th_login = "Логин";
$TLS_th_role = "Роль";
$TLS_warning_delete_user = "Действительно удалить выбранного пользователя?";
</code-php>

==gui/templates/login.tpl==
<code-php>
$TLS_btn_login = "Войти";
$TLS_login_name = "Логин:";
$TLS_lost_password_q = "Забыли пароль?";
$TLS_new_user_q = "Новый пользователь?";
$TLS_password = "Пароль:";
</code-php>

==gui/templates/loginFirst.tpl==
<code-php>
$TLS_btn_add_user_data = "Добавить пользовательские данные";
$TLS_e_mail = "E-mail (нужен, чтобы получить новый пароль):";
$TLS_first_name = "Имя:";
$TLS_last_name = "Фамилия:";
$TLS_link_back_to_login = "Войти еще раз";
$TLS_password_again = "Повторите пароль:";
$TLS_password_mgmt_is_external = "Используется внешнее управление паролями";
</code-php>

==gui/templates/tcMove.tpl==
<code-php>
$TLS_btn_mv = "Переместить";
$TLS_choose_cat = "Выберите группу тестов";
$TLS_inst_move = "Переместить этот тест в другую группу тестов (внутри того же плана тестирования).";
$TLS_title_mv_cp_tc = "Переместить/Копировать тест";
</code-php>

==gui/templates/loginLost.tpl==
<code-php>
$TLS_btn_send = "Выслать пароль";
$TLS_password_reset = "Сбросить пароль";
</code-php>

==gui/templates/tcView.tpl==
<code-php>
$TLS_no_records_found = "Ничего не найдено.";
</code-php>

==gui/templates/execSetResults.tpl==
<code-php>
$TLS_alt_attachment_mgmt = "вложения";
$TLS_alt_notes = "заметки";
$TLS_attachment_mgmt = "вложения";
$TLS_btn_history_off = "Показывать только последний прогон";
$TLS_btn_history_on = "Показывать полную историю прогонов";
$TLS_btn_save_all_tests_results = "Сохранить все результаты прогонов";
$TLS_btn_save_tc_exec_results = "Сохранить результат прогона";
$TLS_bug_mgmt = "Управление багами";
$TLS_build_is_closed = "Сборка закрыта";
$TLS_builds_notes = "Описание сборки";
$TLS_bulk_tc_status_management = "Массовое управление состоянием тестов";
$TLS_date_time_run = "Дата";
$TLS_details = "Подробности";
$TLS_exec_notes = "Заметки";
$TLS_exec_status = "Состояние";
$TLS_execution_history = "История прогонов";
$TLS_img_title_bug_mgmt = "Управление багами";
$TLS_img_title_delete_execution= "Удалить прогон";
$TLS_just_last_execution_for_this_build = "Последний прогон для этой сборки";
$TLS_no_data_available = "Данные отсутствуют";
$TLS_set_all_tc_to = "Установить всем состояние ";
$TLS_show_hide = "Показать / скрыть";
$TLS_tc_not_tested_yet = "Еще не протестировано:";
$TLS_test_cases_cannot_be_executed = "Тесты не могут быть выполнены";
$TLS_test_exec_by = "Протестировано: ";
$TLS_test_exec_expected_r = "Ожидаемые результаты";
$TLS_test_exec_last_run_date = "Самые последние запуски:";
$TLS_test_exec_notes = "Заметки / Описание";
$TLS_test_exec_on_build = " в Сборке";
$TLS_test_exec_result = "Результат";
$TLS_test_exec_steps = "Шаги";
$TLS_test_exec_summary = "Резюме";
$TLS_test_plan_notes = "Заметки по плану тестирования";
$TLS_test_status_not_run = "Не запущен";
$TLS_th_test_case_id = "ID ";
$TLS_th_testsuite = "Группа тестов";
$TLS_title_t_r_on_build = "Результы тестов по Сборке";
$TLS_title_t_r_owner = " Ответственный:";
$TLS_title_test_case = "Тест";
$TLS_version = "Версия";
</code-php>

==gui/templates/inc_testsuite_viewer_ro.tpl==
<code-php>
$TLS_keywords = "Ключевые слова";
$TLS_test_suite = "Группа тестов";
</code-php>

==gui/templates/navBar.tpl==
<code-php>
$TLS_home = "Домой";
$TLS_link_logout = "Выход";
$TLS_product = "Проект";
$TLS_product_role = "Роль проекта";
$TLS_title_edit_personal_data = "Мой профиль";
$TLS_title_execute = "Выполнить";
$TLS_title_results = "Отчеты";
$TLS_title_specification = "Спецификация";
</code-php>

==gui/templates/inc_testsuite_viewer_rw.tpl==

==gui/templates/planAddTC_m1.tpl==
<code-php>
$TLS_add_tc = "Добавить";
$TLS_add_remove_selected_tc_hint = "Операция будет выполнена над ВСЕМИ группами тестов";
$TLS_btn_add_remove_selected_tc = "Добавить / Удалить выбранное";
$TLS_btn_add_selected_tc = "Добавить выбранное";
$TLS_btn_check = "Отметить";
$TLS_btn_uncheck = "Снять отметки";
$TLS_check_uncheck_tc = "Все тесты в этой группе тестов.";
$TLS_check_uncheck_all_checkboxes="отметить все/снять все отметки";
$TLS_has_been_executed = "были выполнены";
$TLS_inactive_testcase = "неактивны";
$TLS_no_testcase_available = "Тестов нет";
$TLS_note_keyword_filter = "Тесты фильтруются по ключевому слову";
$TLS_remove_tc = "Удалить";
$TLS_th_test_case = "Тест";
$TLS_title_add_remove_test_to_plan = "Добавить/Удалить тест(ы) в/из плана тестирования";
$TLS_title_add_test_to_plan = "Добавить тесты в план тестирования";
$TLS_warning_add_remove_selected_tc = "Вы уверены удалить выбранные тесты из этого плана тестирования?";
</code-php>

==gui/templates/planAddTCNavigator.tpl==
<code-php>
$TLS_title_navigator = "Навигатор";
</code-php>

==gui/templates/planPriority.tpl==
<code-php>
$TLS_btn_upd_prio = "Сохранить";
$TLS_title_priority = "Определить приоритеты для плана тестирования";
$TLS_tr_th_importance = "Важность";
$TLS_tr_th_prio_cba = "Приоритет (C/B/A)";
$TLS_tr_th_risk = "Риск/Важность";
</code-php>

==gui/templates/planEdit.tpl==
<code-php>
$TLS_btn_testplan_create = "Создать";
$TLS_cancel = "Отменить";
$TLS_opt_no = "Нет";
$TLS_testplan_question_create_tp_from = "Создать из существующего плана тестирования?";
$TLS_testplan_th_active = "Активный";
$TLS_testplan_th_name = "Имя";
$TLS_testplan_th_notes = "Описание";
$TLS_testplan_title_create = "Создать новый план тестирования";
$TLS_testplan_title_edit = "Править план тестирования";
$TLS_testplan_title_for_project = "для проекта: ";
$TLS_testplan_title_tp_management = "Управление планами тестирования";
$TLS_testplan_txt_notes = <<<END
План тестирования должен содержать ясно определенные задачи, включая временные границы.
Он может содержать тест-активность для выпускаемой версии продукта (включая патчи)
или просто единственный запрос от пользователя.<br/>
В описании можно ссылаться на план и другую документацию по проекту.
Разумно перечислить тестируемые возможности, риски и т.п.<br/>
Можно создать новый план тестирования из существующего ("клонировать").
Будут скопированы следующие элементы: сборки, тесты, приоритеты,
Вехи и роли пользователей.<br/>
План тестирования можно деактивировать/заморозить: т.е. запретить любое изменение
атрибутов или вложенных элементов плана тестирования.
Такие планы тестирования будут видны только на странице отчетов и на этой странице.
END;

$TLS_warning_empty_tp_name = "Пожалуйста, введите имя плана тестирования.";
</code-php>

==gui/templates/planNew.tpl==
<code-php>
$TLS_testplan_btn_edit = "Сохранить";
$TLS_testplan_btn_new = "Создать";
$TLS_testplan_menu_create = "Создать";
$TLS_testplan_menu_edit = "Править";
$TLS_testplan_menu_list = "Список";
</code-php>

==gui/templates/planMilestones.tpl==
<code-php>
$TLS_alt_delete_milestone = "Удалить веху?";
$TLS_btn_edit_milestone = "Править";
$TLS_btn_new_milestone = "Создать";
$TLS_info_milestones_date = "Веха не может иметь дату раньше чем 'сегодня'";
$TLS_no_milestones = "Для этого плана тестирования вехи не определены.";
$TLS_popup_delete_milestones = "Вы уверены удалить веху %NAME% ?";
$TLS_warning_empty_milestone_name="Укажите имя вехи!";

$TLS_th_date_format = "Целевая Дата";
$TLS_th_perc_a_prio = "% A-приоритет";
$TLS_th_perc_b_prio = "% B-приоритет";
$TLS_th_perc_c_prio = "% C-приоритет";
$TLS_title_existing_milestones = "Существующие вехи";
$TLS_title_milestones = "Вехи для плана тестирования";
$TLS_title_new_milestone = "Новая Веха";
</code-php>

==gui/templates/projectedit.tpl==
<code-php>
$TLS_btn_activate = "Активировать";
$TLS_btn_del = "Удалить";
$TLS_btn_edit_del = "Править / Удалить";
$TLS_btn_inactivate = "Деактивировать";
$TLS_caption_edit_product = "Править проект";
$TLS_caption_new_product = "Создать проект";
$TLS_color = "Цвет";
$TLS_enable_requirements = "Включить функциональность Требований";
$TLS_info_failed_loc_prod = "Не удалось локализовать проект.";
$TLS_notes = "Заметки";
// Warning!!! - if JS string you must use \\n to get \n
$TLS_popup_product_delete = <<<END
Внимание! Вы собираетесь необратимо удалить все данные связанные проектом:
результаты тестов, планы тестирования, тесты и т.п. \\n
Вместо удаления вы можете деактивировать проект. \\n
Если вы всё-таки настроены удалить проект, рекомендуем вам сначала
сделать бэкап базы данных. \\n
Итак, вы по прежнему уверены удалить проект?
END;
$TLS_warning_empty_tproject_name = "Обязательно задайте имя проекта!";
</code-php>

==gui/templates/reqAssign.tpl==
<code-php>
$TLS_please_select_a_req = "Пожалуйста, выберите требование";
$TLS_req_msg_norequirement66 = "Требования нет";
$TLS_req_title_assign = "Привяжите требования к тесту";
$TLS_req_title_assigned = "Привязанные требования";
$TLS_req_title_unassigned = "Доступные требования";
$TLS_warning_req_tc_assignment_impossible = <<<END
<p>
Вы <b>не можете</b> делать привязку по одной из следующих причин:
<ul>
<li>Не определено ни одной спецификации требования;
<li>Спецификации требований пусты.
</ul>
END;
</code-php>

==gui/templates/tcEdit.tpl==
<code-php>
$TLS_title_edit_tc = "Править тест";
$TLS_warning_editing_executed_tc = "Внимание: Этот версия теста уже выполнялась";
</code-php>

==gui/templates/planOwner.tpl==
<code-php>
$TLS_assign_ownership = "Назначить ответственного";
$TLS_def_prio_rules = "Определить правила приоритетов";
$TLS_opt_label_none = "нет";
$TLS_th_imp = "Важность";
$TLS_th_owner = "Тестировщик";
$TLS_th_risk = "Риск";
$TLS_th_test_suite = "Группа тестов";
$TLS_title_plan_ownership = "Владелец плана тестирования";
</code-php>

==gui/templates/tcView_viewer.tpl==
<code-php>
$TLS_activate_this_tcversion = "Активировать эту версию";
$TLS_Requirements = "Требования";
$TLS_btn_del_this_version = "Удалить эту версию";
$TLS_btn_edit = "Править";
$TLS_btn_mv_cp = "Переместить/Копировать";
$TLS_btn_new_version = "Создать новую версию";
$TLS_can_not_edit_tc = "Вы не можете редактировать эту версию, т.к. она уже выполнялась";
$TLS_deactivate_this_tcversion = "Деактивировать эту версию";
$TLS_tcversion_is_inactive_msg = "Эта версия <b>неактивна</b>, и не будет доступна для включения в план тестирования";
</code-php>

==gui/templates/planRemoveTC_m1.tpl==
<code-php>
$TLS_btn_remove_selected_tc = "Удалить выбранные тесты tcs";
$TLS_remove_ok = "Удаление прошло успешно ok";
$TLS_title_remove_test_from_plan = "Удалить тест из плана тестирования";
</code-php>

==gui/templates/planTesters.tpl==
<code-php>
$TLS_btn_save = "Сохранить";
</code-php>

==gui/templates/keywordsAssign.tpl==
<code-php>
$TLS_keyword_assignment_empty_tsuite = "В этой группе тестов нет тестов => ключевое слово привязать нельзя";
$TLS_menu_assign_kw_to_tc = "Привязать к тестам";
$TLS_menu_manage_keywords = "Управление ключевыми словами";
$TLS_title_keywords = "Ключевые слова";
</code-php>

==gui/templates/planTestersNavigator.tpl==
<code-php>
$TLS_label_list_of = "Список ";
$TLS_opt_test_plans = "планов тестирования";
$TLS_opt_users = "пользователей";
</code-php>

==gui/templates/planUpdateTC.tpl==
<code-php>
$TLS_btn_upd_ck_tc = "Изменить выбранные тест(ы)";
$TLS_info_all_tc_uptodate = "Все тесты актуальны.";
$TLS_th_category = "Группа тестов";
$TLS_th_component = "Группа тестов";
$TLS_th_id_tc = "[ID] теста";
$TLS_th_reason = "Причина правки";
$TLS_th_spec_version = "Специальная версия";
$TLS_th_status = "Состояние";
$TLS_th_suite_version = "Версия группы тестов";
$TLS_th_update = "Изменить";
$TLS_title_upd_mod_tc = "Изменить исправленные тесты в ";
</code-php>

==gui/templates/keywordsView.tpl==
<code-php>
$TLS_alt_delete_keyword = "Удалить ключевое слово?";
$TLS_btn_create_keyword = "Создать ключевое слово";
$TLS_btn_edit_keyword = "Править";
$TLS_btn_import_keywords = "Импорт";
$TLS_th_keyword = "Ключевое слово";
$TLS_warning_delete_keyword = "Вы уверены удалить ключевое слово?";
$TLS_warning_enter_at_least1 = "Пожалуйста, введите хотя бы ";
$TLS_warning_enter_at_least2 = " символов.";
$TLS_warning_enter_less1 = "Пожалуйста, используйте не больше чем";
$TLS_warning_enter_less2 = " символов.";
</code-php>

==gui/templates/reqexport.tpl==
<code-php>
$TLS_title_req_export_to = "Экспорт требований";
</code-php>

==gui/templates/resultsAllBuilds.tpl==
<code-php>
$TLS_test_status_blocked = "Блокирован";
$TLS_test_status_failed = "Сбой";
$TLS_test_status_passed = "Пройден";
$TLS_th_build = "Сборка";
$TLS_th_tc_total = "Всего тестов";
</code-php>

==gui/templates/resultsBugs.tpl==
<code-php>
$TLS_date = "Дата:";
$TLS_printed_by = "Напечатано:";
$TLS_title_test_case_bugs = "Баги по тесту";
$TLS_title_test_case_timestamp = "Временная метка теста";
$TLS_title_test_case_title = "Заголовок теста";
$TLS_title_test_suite_name = "Имя группы тестов";
</code-php>

==gui/templates/resultsBuild.tpl==
<code-php>
$TLS_title_met_of_build = "Метрики сборки";
</code-php>

==gui/templates/resultsByStatus.tpl==
<code-php>
$TLS_info_test_results = <<<END
<p>
Показываются результаты только последнего теста.
<p>
В частности, тесты скрыты, если результаты тестов для следующей сборки
имеют статус отличный от "в процессе".
END;

$TLS_th_bugs = "Баги";
$TLS_th_date = "Дата";
$TLS_th_run_by = "Запустил:";
</code-php>

==gui/templates/resultsGeneral.tpl==
<code-php>
$TLS_title_gen_test_rep = "Общие метрики плана тестирования";
</code-php>

==gui/templates/resultsMoreBuilds_query_form.tpl==
<code-php>
$TLS_excel_format = "MS Excel";
$TLS_html_format = "HTML";
$TLS_last_status_any = "Любой";
$TLS_last_status_blocked = "Блокирован";
$TLS_last_status_failed = "Сбой";
$TLS_last_status_not_run = "Не стартовал";
$TLS_last_status_passed = "Пройден";
$TLS_select_builds_header = "Выберите сборку(и)";
$TLS_select_components_header = "Выберите группу тестов";
$TLS_select_keyword_header = "Выберите ключевое слово";
$TLS_select_last_result_header = "Выберите последний результат";
$TLS_select_owner_header = "Выберите владельца";
$TLS_select_report_format_header = "Выберите формат отчета";
$TLS_submit_query = "Выполнить запрос";
$TLS_test_plan_header = "План тестирования: ";
$TLS_query_metrics_report = "Запросить отчет по метрикам";
$TLS_enter_start_time = "Введите начальное время";
$TLS_enter_end_time = "Введите конечное время";
$TLS_year = "год";
$TLS_month = "месяц";
$TLS_day = "день";
$TLS_hour = "час";
$TLS_search_in_notes = "поиск строки в заметках";
$TLS_executor = "исполнитель";
</code-php>

==gui/templates/resultsMoreBuilds_report.tpl==
<code-php>
$TLS_caption_show_collapse = "Показать/Свернуть";
$TLS_caption_user_selected_query_parameters = "Параметры запроса";
$TLS_not_yet_executed = "Еще не выполнялся";
$TLS_show_hide_all = "Показать/Скрыть все";
$TLS_th_builds = "Сборка(и)";
$TLS_th_execution_ts = "Время";
$TLS_th_last_result = "Последний результат";
$TLS_th_report_format = "Тип отчета";
$TLS_th_test_plan = "План тестирования";
$TLS_th_test_suites = "Группа(ы) тестов";
$TLS_th_tester_id = "Тестировщик";
$TLS_th_total_block = "# блокированных ";
$TLS_th_total_cases = "# тестов";
$TLS_th_total_fail = "# сбоев";
$TLS_th_total_not_run = "# не стартовавших";
$TLS_th_total_pass = "# выполненных";
$TLS_th_start_time = "Время начала";
$TLS_th_end_time = "Время окончания";
$TLS_th_executor = "Исполнитель";
$TLS_th_search_notes_string = "в заметках искать строку";
$TLS_true = "да";
$TLS_false = "нет";
$TLS_display_suite_summaries = "Показать итоги по группе тестов";
$TLS_display_query_params = "Показать параметры запроса";
$TLS_display_totals = "Показать суммарную информацию";
</code-php>

==gui/templates/resultsReqs.tpl==
<code-php>
$TLS_req_title_blocked = "Заблокировано требований";
$TLS_req_title_failed = "Нарушено требований";
$TLS_req_title_notrun = "Непроверенных требований";
$TLS_req_title_passed = "Выполнено требований";
$TLS_title_result_req_testplan = "Результаты тестов основанных на спецификации требований";
$TLS_title_test_plan = "План тестирования";
</code-php>

==gui/templates/resultsSend.tpl==
<code-php>
$TLS_btn_send_report = "Послать отчет";
$TLS_check_send_to_me = "Послать отчет самому себе";
$TLS_mail_body = "Тело письма:";
$TLS_mail_report = "Отчет:";
$TLS_mail_subject = "Тема письма:";
$TLS_mail_to = "Кому:";
$TLS_status_for_build = "Состояние сборки";
$TLS_tp_status = "Общее состояние плана тестирования";
$TLS_tp_status_for_build = "Состояние плана тестирования для сборки";
</code-php>

==gui/templates/resultsTC.tpl==
<code-php>
$TLS_generated_by_TestLink_on="Сформировано системой TestLink, ";
</code-php>

==gui/templates/tcEdit_m2.tpl==

==gui/templates/tcPrintNavigator.tpl==
<code-php>
$TLS_caption_print_opt = "Настройки печати";
$TLS_tr_td_show_as = "Показать как";
</code-php>

==gui/templates/tcReorder.tpl==
<code-php>
$TLS_no_tc_to_reorder = "Нет тестов для переупорядочивания.";
$TLS_title_change_tc_order = "Изменить порядок тестов в этой группе тестов.";
</code-php>

==gui/templates/tcTree.tpl==
<code-php>
$TLS_button_refresh = "Обновить";
$TLS_button_update_tree = "Обновить дерево";
$TLS_do_auto_update = "Обновлять дерево после каждой операции";
$TLS_no_tc_spec_av = "Нет тест-спецификаций.";
</code-php>

==gui/templates/tc_exec_assignment.tpl==
<code-php>
$TLS_btn_do = "Пуск";
$TLS_btn_update_selected_tc = "Изменить выбранные тесты";
$TLS_title_tc_exec_assignment = "Назначить прогоны тестов для плана тестирования ";
$TLS_user = "Пользователь";
$TLS_user_bulk_assignment = "Массовое назначение ответственных пользователей";
</code-php>

==gui/templates/testSetNavigator.tpl==

==gui/templates/userInfo.tpl==
<code-php>
$TLS_btn_change_passwd = "Сменить пароль";
$TLS_btn_upd_user_data = "Изменить";
$TLS_th_new_passwd = "Новый пароль";
$TLS_th_new_passwd_again = "Повторите новый пароль";
$TLS_th_old_passwd = "Старый пароль";
$TLS_title_account_settings = "Настройки профиля";
$TLS_title_change_your_passwd = "Сменить ваш пароль";
$TLS_warning_different_pwd = "Пожалуйста, повторите еще раз ваш новый пароль. Введенные пароли не совпадают.";
$TLS_warning_empty_pwd = "Пароль должен быть не пуст!";
$TLS_your_password_is_external = "Ваш пароль ведётся во внешней системе";
</code-php>

==gui/templates/usersassign.tpl==
<code-php>
$TLS_TestProject = "проект";
$TLS_User = "Пользователь";
$TLS_btn_change = "Изменить";
$TLS_caption_assign_testplan_user_roles = "Назначить роли плана тестирования пользователям";
$TLS_caption_assign_testproject_user_roles = "Назначить роли проекта пользователям";
$TLS_menu_assign_testproject_roles = "Назначить роли проекта";
$TLS_th_roles = "Роли";
$TLS_title_assign_roles = "Назначить роли";
</code-php>

==gui/templates/usersedit.tpl==
<code-php>
$TLS_button_reset_password = "Сбросить пароль";
$TLS_caption_user_details = "Свойства пользователя";
$TLS_th_password = "Пароль";
$TLS_warning_empty_first_name = "Пожалуста, введите имя";
$TLS_warning_empty_last_name = "Пожалуйста, введите фамилию";
$TLS_warning_empty_login = "Пожалуйста, введите логин";
</code-php>

==gui/templates/attachmentupload.tpl==
<code-php>
$TLS_attachment_upload_ok="Файл загружен.";
$TLS_enter_attachment_title = "Введите заголовок для этого вложения.";
$TLS_import_was_ok = "Импорт прошел успешно.";
$TLS_max_size_cvs_file = "Максимальный размер файла:";
$TLS_title_upload_attachment = "Загрузить вложение";
</code-php>

==gui/templates/rolesview.tpl==
<code-php>
$TLS_N_A = "N/A";
$TLS_alt_delete_role = "Удалить роль";
$TLS_alt_edit_role = "Править роль";
$TLS_btn_confirm_delete = "Удалить";
$TLS_no_roles = "Нет ролей";
$TLS_title_roles = "Доступные роли";
$TLS_warning_users_will_be_reset = "'Задетым пользователям' будет назначена гостевая роль!";
</code-php>

==gui/templates/tcexport.tpl==
<code-php>
$TLS_export_with_keywords = "Экспортировать с ключевыми словами";
</code-php>

==gui/templates/buildView.tpl==
<code-php>
$TLS_alt_active_build = "Активная сборка";
$TLS_alt_edit_build = "Редактировать эту сборку";
$TLS_alt_open_build = "Открыть сборку";
$TLS_btn_build_create = "Создать";
$TLS_no_builds = "В этот плане тестирования сборок не определено.";
$TLS_th_description = "Описание";
$TLS_th_open = "Открыть";
$TLS_title_build_list = "Список существующих сборок";
$TLS_warning_delete_build = <<<END
<p>Вы действительно хотите уничтожить эту сборку? <p>
Все связанные данные (в частности, результаты тестов) будут также удалены!";
END;
</code-php>

==gui/templates/planView.tpl==
<code-php>
$TLS_testplan_alt_delete_tp = "Удалить этот план тестирования?";
$TLS_testplan_alt_edit_tp = "Править план тестирования";
$TLS_testplan_msg_delete_confirm = <<<END
Вы уверены, что хотите удалить план тестирования? <p>
План тестирования можно деактивировать не удаляя.
END;

$TLS_testplan_th_delete = "Удалить";
$TLS_testplan_title_list = "Список планов тестирования";
$TLS_testplan_txt_empty_list = <<<END
Ни одного плана тестирования не определено! <p>
Чтобы воспользоваться функциональностью прогонов тестов, нужно
создать хотя бы один.
END;
$TLS_alt_active_testplan = "Активный план тестирования";
</code-php>

==gui/templates/mainPage_left.tpl==
<code-php>
$TLS_href_assign_user_roles = "Назначить пользовательские роли";
$TLS_href_browse_tc = "Просмотр тестов";
$TLS_href_cfields_management = "Управление пользовательскими полями";
$TLS_href_cfields_tproject_assign = "Привязка пользовательских полей";
$TLS_href_create_product = "Создать новый проект";
$TLS_href_edit_product = "Править/Удалить проект";
$TLS_href_edit_tc = "Редактировать тесты";
$TLS_href_keywords_assign = "Привязать ключевые слова";
$TLS_href_keywords_manage = "Управление ключевыми словами";
$TLS_href_keywords_view = "Просмотр ключевых слов";
$TLS_href_print_tc = "Печать тестов";
$TLS_href_req_assign = "Привязать требования";
$TLS_href_req_spec = "Спецификация требований";
$TLS_href_roles_management = "Управление ролями";
$TLS_href_search_tc = "Искать тест(ы)";
$TLS_href_user_management = "Управление пользователями";
$TLS_title_requirements = "Требования";
$TLS_title_test_spec = "Спецификации тестов";
$TLS_title_product_mgmt = "Управление проектами";
</code-php>

==gui/templates/mainPage_right.tpl==
<code-php>
$TLS_filter_tp_by_product = "Фильтровать план тестирования по проектам";
$TLS_href_add_test_case = "Добавить тест(ы)";
$TLS_href_build_new = "Управление сборками";
$TLS_href_execute_test = "Выполнить тесты";
$TLS_href_plan_assign_priority = "Установить приоритеты";
$TLS_href_plan_define_priority = "Определить правила приоритетов";
$TLS_href_plan_management = "Управление планами тестирования";
$TLS_href_plan_mstones = "Управление вехами";
$TLS_href_print_tc_suite = "Печать плана тестирования";
$TLS_href_remove_test_case = "Удалить тест(ы)";
$TLS_href_rep_and_metrics = "Отчеты и метрики";
$TLS_href_tc_exec_assignment = "Поручить прогон тестов";
$TLS_href_upd_mod_tc = "Сохранить измененные тесты";
$TLS_msg_no_rights_for_tp = "- недоступен (У вас нет доступа ни для одного плана тестирования)";
$TLS_testplan_role = "Роль плана тестирования";
$TLS_title_test_case_suite = "Содержание плана тестирования";
$TLS_title_test_execution = "Выполнение плана тестирования";
$TLS_title_test_plan_mgmt = "Управление планами тестирования";
$TLS_href_newest_tcversions = "Показать тесты с самыми свежими версиями";
</code-php>

==lib/execute/bug_add.php==
<code-php>
$TLS_bug_added = "Баг добавлен";
$TLS_error_bug_does_not_exist_on_bts="Бага с таким ID не зарегистрировано в BTS!";
$TLS_error_wrong_BugID_format = "Неверный формат BugID!";
</code-php>

==lib/execute/bug_delete.php==
<code-php>
$TLS_bugdeleting_was_ok = "Баг успешно удален.";
</code-php>

==lib/functions/doAuthorize.php==
<code-php>
$TLS_error_ldap_auth_failed = "LDAP-аутентификация не удалась";
$TLS_error_ldap_bind_failed = "Не удалось выполнить LDAP-binding";
$TLS_error_ldap_server_connect_failed = "Не удалось соединится с LDAP-сервером";
$TLS_error_ldap_update_failed = "Обновление LDAP не удалось";
$TLS_error_ldap_user_not_found = "LDAP-пользователь не найден";
</code-php>

==lib/functions/product.inc.php==
<code-php>
$TLS_info_product_delete_fails = "При удалении этого проекта произошла ошибка";
</code-php>

==lib/functions/results.inc.php==
<code-php>
$TLS_trep_failing = "Провалены";
$TLS_trep_passing = "Прошли";
$TLS_trep_status_for_build = "Состояние для сборки";
$TLS_trep_status_for_ts = "Состояние для группы тестов";
$TLS_unassigned = "Не назначены";
</code-php>

==lib/functions/resultsMoreBuilds.inc.php==
<code-php>
$TLS_bugs = "Связанные Баги";
$TLS_builds_selected = "Сборка(и)";
$TLS_case_not_run_warning = "Тест не запущен";
$TLS_category_header = "Группа тестов =";
$TLS_daterun = "Дата запуска";
$TLS_last_status = "Последнее состояние";
$TLS_number_blocked = "# блокированных";
$TLS_number_cases = "# тестов";
$TLS_number_executions = "# тест-пусков";
$TLS_number_failed = "# тест-сбоев";
$TLS_number_not_run = "# не запущено";
$TLS_number_passed = "# пройденных";
$TLS_owner = "Тестировщик";
$TLS_owner_header = "Tester =";
$TLS_runby = "Запущен тестировщиком ";
$TLS_test_plan_name = "План тестирования";
</code-php>

==lib/functions/roles.inc.php==
<code-php>
$TLS_desc_cfield_management = "Управление пользовательскими полями";
$TLS_desc_cfield_view = "Просмотр пользовательских полей (read-only)";
$TLS_desc_mgt_modify_key = "Управление ключевыми словами";
$TLS_desc_mgt_modify_product= "Управление проектами";
$TLS_desc_mgt_modify_req = "Управление требованиями";
$TLS_desc_mgt_modify_tc = "Создание/правка тестов";
$TLS_desc_mgt_modify_users = "Управление пользователями";
$TLS_desc_mgt_view_key = "Просмотр ключевых слов (read-only)";
$TLS_desc_mgt_view_req = "Просмотр требований (read-only)";
$TLS_desc_mgt_view_tc = "Просмотр тестов (read-only)";
$TLS_desc_role_management = "Управление ролями";
$TLS_desc_testplan_create_build = "Создание/редактирование сборки";
$TLS_desc_testplan_execute = "Выполнение плана тестирования";
$TLS_desc_testplan_metrics = "Метрики плана тестирования";
$TLS_desc_testplan_planning = "Составление плана тестирования";
$TLS_desc_user_role_assignment = "Назначение ролей";
$TLS_error_duplicate_rolename = "Роль с таким именем уже есть!";
$TLS_error_role_no_rights = "Вы не можете создать роль без каких-либо прав!";
$TLS_error_role_no_rolename = "Вам нужно ввести имя для этой роли.";
$TLS_mgt_testplan_create = "Создать/править план тестирования";
</code-php>

==lib/functions/testproject.class.php==
<code-php>
$TLS_error_creating_req_spec = "Ошибка при создании спецификации требования";
$TLS_info_product_name_empty = "Нельзя давать пустое имя.";
$TLS_keyword_already_exists = "Такое ключевое слово уже есть";
$TLS_string_contains_bad_chars = "Введенная строка содержит недопустимые символы.";
$TLS_warning_duplicate_req_title= "Требование с таким заголовком уже есть.";
</code-php>

==lib/functions/requirements.inc.php==
<code-php>
$TLS_conflict = "Конфликт";
$TLS_error_deleting_req = "Ошибка при удалении требования(й).";
$TLS_error_inserting_req = "Ошибка при вставке требования(й).";
$TLS_error_updating_req = "Ошибка при правке требования(й).";
$TLS_error_updating_reqspec = "Ошибка при правке спецификаций требований.";
$TLS_file_is_not_xml = "Файл не распознан как корректный XML, и не может быть использован.";
$TLS_ok = "OK";
$TLS_req_import_format_description1 = " - тип CSV требует три поля на каждую запись: 'req_doc_id','title','description'";
$TLS_req_import_format_description2 = " - CSV, экспортированный из DOORS требует запись-заголовок.";
$TLS_req_import_result_overwritten = "перезаписано!";
$TLS_req_import_result_skipped = "пропущено";
$TLS_req_state_not_testable = "не тестируемо";
$TLS_req_state_valid = "актуально";
$TLS_the_format_req_xml_import = "Неверный XML-формат для импорта требований";
$TLS_warning_duplicate_reqdoc_id = "Не уникальный (дублирующий) id документа";
</code-php>

==lib/functions/testsuite.class.php==
<code-php>
$TLS_component_name_already_exists = "Группа тестов с таким именем уже зарегистрирована";
$TLS_testsuite = "Группа тестов";
</code-php>

==lib/functions/exec.inc.php==
<code-php>
$TLS_test_results_submitted = "Результаты тестов отправлены.";
</code-php>

==lib/functions/print.inc.php==
<code-php>
$TLS_author = "Автор";
$TLS_printed_by_TestLink_on = "Распечатано TestLink'ом ";
$TLS_title_toc = "Содержание";
$TLS_passfail = "Пройден / Провален";
$TLS_testnotes = "Заметки к тесту";
</code-php>

==lib/functions/testcase.class.php==
<code-php>
$TLS_testcase_name_already_exists = "Тест с таким именем уже есть!";
$TLS_the_format_tc_xml_import = "";
</code-php>

==lib/functions/info.inc.php==
<code-php>
$TLS_email_sent_message = "Ваше письмо отослано.";
</code-php>

==lib/functions/users.inc.php==
<code-php>
$TLS_Unknown = "Неизвестно";
$TLS_duplicate_login = "Пользователь с таким логином уже есть!";
$TLS_login_must_not_be_empty = "Логин не должен быть пустым!";
$TLS_wrong_old_password = "Старый пароль неверен!";
</code-php>

==lib/functions/email_api.php==
<code-php>
$TLS_stmp_host_unconfigured = "Некорректно указан SMTP host!";
</code-php>

==lib/functions/common.php==

==lib/functions/configCheck.php==
<code-php>
$TLS_attachments_dir = "каталог для вложений:";
$TLS_bts_connection_problems = <<<END
Не удалось соединиться с вашей Bug Tracking System.<p>
Пожалуйста, проверьте настройки.<p>
Будьте внимательны, эта проблема
снижает производительность TestLink'а.
END;

$TLS_but_directory_is_not_writable = "Каталог закрыт для записи!";
$TLS_directory_is_writable = "Каталог открыт для записи.";
$TLS_does_not_exist = "не существует";
$TLS_exists = "существует";
$TLS_ldap_extension_not_loaded=<<<END
Метод аутентификации указан как LDAP </br>
однако PHP/LDAP extension не загружено =>
Вам не удастся войти в систему.
Пожалуйста, свяжитесь с администратором TestLink'а.
END;
$TLS_sec_note_admin_default_pwd = "Вам необходимо сменить пароль по умолчанию у пользователя 'admin'!";
$TLS_sec_note_remove_install_dir = "Инсталляционный каталог должен быть удален!";
</code-php>

==lib/general/frmWorkArea.php==
<code-php>
$TLS_create_a_build = "Создать новую сборку";
$TLS_no_build_warning_part1 = "Ни одной сборки для этого тест плана не создано.";
$TLS_no_build_warning_part2 = "Создайте их или попросите об этом свое руководство.";
</code-php>

==lib/general/myTPInfo.php==
<code-php>
$TLS_no_testplans_available = "К сожалению, ни одного плана тестирования не доступно";
</code-php>

==lib/general/tlsmarty.inc.php==

==lib/keywords/keywords.inc.php==
<code-php>
$TLS_empty_keyword_no = "Ключевое слово должно быть непустым!";
$TLS_keywords_char_not_allowed = "Запятые и кавычки недопустимы в ключевых словах!";
$TLS_tc_kw_update_fails1 = "Тест";
$TLS_tc_kw_update_fails2 = " дал сбой ";
$TLS_the_format_keyword_csv_import = "keyword;notes";
$TLS_the_format_keyword_xml_import = "<keywords><keyword name=\"name\">Notes</keyword></keywords>";
</code-php>

==lib/keywords/keywordsView.php==
<code-php>
$TLS_kw_delete_fails = "Не удалось удаление ключевого слова!";
$TLS_kw_update_fails = "Не удалась правка ключевого слова!";
</code-php>

==lib/keywords/keywordsAssign.php==
<code-php>
$TLS_assigned_kword = "Связанные ключевые слова";
$TLS_available_kword = "Доступные ключевые слова";
</code-php>

==lib/plan/buildNew.php==
<code-php>
$TLS_cannot_add_build = "Невозможно добавить сборку!";
$TLS_cannot_delete_build = "Невозможно удалить сборку!";
$TLS_cannot_update_build = "Ошибка при правке сборки!";
$TLS_warning_duplicate_build = "Сборка с таким идентификатором уже есть.";
</code-php>

==lib/plan/plan.inc.php==
<code-php>
$TLS_warning_empty_milestone_name = "Обязательно введите имя для вехи!";
$TLS_warning_enter_valid_date = "Введенная дата некорректна!";
$TLS_warning_invalid_percentage_value = "Значения-проценты должны быть от 0 to 100 (%)";
$TLS_warning_milestone_date = "Веха не может иметь дату раньше чем 'сегодня'!";
$TLS_warning_percentage_value_higher_than_100 = "Сумма всех значений-процентов не должна быть больше 100!";
</code-php>

==lib/plan/planMilestones.php==
<code-php>
$TLS_milestone_delete_fails = "Не удалось удалить веху!";
$TLS_warning_milestone_add_failed = "Не удалось добавить веху!";
$TLS_warning_milestone_update_failed = "Не удалось править веху!";
</code-php>

==lib/plan/planOwner.php==
<code-php>
$TLS_opt_imp_high = "Высокая";
$TLS_opt_imp_low = "Низкая";
$TLS_opt_imp_medium = "Средняя";
</code-php>

==lib/plan/planTestersEdit.php==
<code-php>
$TLS_title_assign_tp = "Поручить планы тестирования пользователю: ";
$TLS_title_assign_users = "Назначить пользователей на план тестирования: ";
</code-php>

==lib/plan/planTestersNavigator.php==
<code-php>
$TLS_nav_test_plan = "Навигатор - Планы тестирования";
$TLS_nav_users = "Навигатор - Пользователи";
</code-php>

==lib/plan/planUpdateTC.php==
<code-php>
$TLS_category_has_changed = "Группа тестов изменена";
$TLS_component_has_changed = "Группа тестов изменена";
$TLS_deleted = "удалена";
$TLS_different_versions = "Различные версии";
$TLS_plan_update_no_tc_updated = "Ни один тест не изменен";
$TLS_planupdate_tc_deleted1 = "Тест";
$TLS_planupdate_tc_deleted2 = "был удален.";
$TLS_planupdate_tc_updated1 = "Тест";
$TLS_planupdate_tc_updated2 = "был изменен.";
$TLS_tcorder_has_changed = "Порядок тестов был изменен";
$TLS_updated = "изменен";
</code-php>

==lib/plan/testSetNavigator.php==
<code-php>
$TLS_title_test_plan_navigator = "Навигация по планам тестирования";
</code-php>

==lib/plan/testSetRemove.php==
<code-php>
$TLS_tcase_removed_from_tplan="тест удален из плана тестирования";
$TLS_multiple_tcase_removed_from_tplan="Тесты удалены из плана тестирования";
</code-php>

==lib/plan/planEdit.php==
<code-php>
$TLS_testplan_created_ok = "План тестирования был создан";
$TLS_update_tp_failed1 = "Правка плана тестирования '";
$TLS_update_tp_failed2 = "' не удалась";
$TLS_warning_duplicate_tplan_name = "План тестирования с таким именем уже есть. Выберите другое имя!";
</code-php>

==lib/print/selectData.php==
<code-php>
$TLS_opt_show_doc_header = "Показать заголовок документа";
$TLS_opt_show_tc_body = "Показать тело теста";
$TLS_opt_show_tc_summary = "Показать резюме теста";
$TLS_opt_show_toc = "Показать Содержание";
$TLS_opt_show_tc_author = "Показать автора теста";
$TLS_opt_show_passfail = "Показать статус «пройден/провален» и заметки";
$TLS_title_tc_print_navigator = "Навигация - Печать спецификации тестов";
$TLS_title_tp_print_navigator = "Навигация - Печать плана тестирования";
</code-php>

==lib/project/projectedit.php==
<code-php>
$TLS_error_product_name_duplicate = "Уже есть проект с именем %s. <br>Пожалуйста, выберите другое имя";
$TLS_info_no_more_prods = "проектов больше нет.";
$TLS_info_product_activated = "проект активирован.";
$TLS_info_product_inactivated = "проект деактивирован.";
$TLS_info_product_not_deleted_check_log = "Не удалось удалить проект. Проверьте лог TestLink'а.";
$TLS_info_product_was_deleted = "проект успешно удален.";
$TLS_refer_to_log = " Пожалуйста, изучите лог TestLink'а для дополнительной информации.";
$TLS_test_project_activated = "проект %s успешно активирован";
$TLS_test_project_created = "проект %s успешно создан";
$TLS_test_project_deleted = "проект %s успешно удален";
$TLS_test_project_inactivated = "проект %s успешно деактивирован";
$TLS_test_project_updated = "проект %s успешно отредактирован";
$TLS_test_project_update_failed = "Правка проекта %s не удалась!";
</code-php>

==lib/results/charts.php==
<code-php>
$TLS_maani_copyright = "flash technology предоставлена http://www.maani.us";
$TLS_graphical_reports = "Графические отчеты";
$TLS_overall_metrics = "Общие метрики";
$TLS_results_by_keyword = "Результаты по ключевому слову";
$TLS_results_by_tester = "Рузультаты по тестировщику";
$TLS_results_top_level_suites = "Результаты по топ группам тестов";
</code-php>

==lib/req/reqImport.php==
<code-php>
$TLS_file_is_not_ok_for_import_type = "Кажется тип файла не совпадает с выбранным для импорта типом";
$TLS_file_is_not_text = "Это не текстовый файл. Использовать нельзя.";
$TLS_please_choose_req_file = "Пожалуйста, выберите файл для загрузки";
$TLS_req_import_finished = "Импорт завершен!";
</code-php>

==lib/req/reqSpecView.php==
<code-php>
$TLS_cant_create_tc_from_req_nothing_sel = "Пожалуйста, выберите требование!";
$TLS_req_created = "Требование %s успешно создано.";
</code-php>

==lib/req/reqTcAssign.php==
<code-php>
$TLS_req_msg_noselect = "Ничего не выбрано";
$TLS_req_msg_notupdated_coverage = "Покрытие не обновлено для Требований: ";
</code-php>

==lib/results/resultsBugs.php==
<code-php>
$TLS_title_test_report_all_builds = "Отчет: Результаты тестов для всех сборок";
</code-php>

==lib/results/resultsAllBuilds.php==
<code-php>
$TLS_title_metrics_x_build = " - Результаты тестов. Метрики X Сборки";
</code-php>

==lib/results/resultsByStatus.php==
<code-php>
$TLS_list_of_blocked = "Список блокированных тестов";
$TLS_list_of_failed = "Список проваленных тестов";
$TLS_list_of_not_run = "Список незапущенных тестов";
</code-php>

==lib/results/resultsTC.php==

==lib/results/resultsNavigator.php==
<code-php>
$TLS_link_charts="Диаграммы";
$TLS_link_report_blocked_tcs = "Блокированные тесты";
$TLS_link_report_failed = "Проваленные тесты";
$TLS_link_report_general_tp_metrics = "Общие метрики плана тестирования";
$TLS_link_report_metrics_active_build = "Метрики активной сборки";
$TLS_link_report_metrics_more_builds = "Запрос метрик";
$TLS_link_report_not_run="Не запущенные тесты";
$TLS_link_report_overall_build = "Общий статус сборки";
$TLS_link_report_reqs_coverage = "Отчет о выполнении требований";
$TLS_link_report_test = "Отчет по тестам";
$TLS_link_report_total_bugs = "Всего багов по каждому тесту";
</code-php>

==lib/results/resultsSend.php==
<code-php>
$TLS_send_to_empty_email_warning = "Пожалуйста, введите правильный email.";
$TLS_warning_create_build_first = "Сначала Вы должны создать или импортировать сборки.";
</code-php>

==lib/results/displayMgr.php==
<code-php>
$TLS_error_sendreport_no_email_credentials = "Email для этого пользователя не указан, пожалуйста, укажите его в настройках своего профиля";
</code-php>

==lib/testcases/archive.inc.php==

==lib/testcases/listTestCases.php==

==lib/testcases/tcImport.php==
<code-php>
$TLS_please_choose_file_to_import = "Пожалуйста, выберите файл для импорта";
$TLS_title_tc_import_to = "Импорт тестов";
$TLS_title_tsuite_import_to = "Импорт группы тестов";
$TLS_wrong_xml_tcase_file = "Некорректный XML в файле с тестами";
$TLS_wrong_xml_tsuite_file = "Некорректный XML в файле с группой тестов";
</code-php>

==lib/testcases/tcexport.php==
<code-php>
$TLS_no_testcases_to_export = "Нет тестов для экспорта";
$TLS_no_testsuites_to_export = "Нет группы тестов для экспорта";
$TLS_title_tc_export = "Экспорт теста";
$TLS_title_tc_export_all = "Экспортировать все тесты";
$TLS_title_tsuite_export = "Экспортировать все группы тестов";
$TLS_title_tsuite_export_all = "Экспортировать все группы тестов";
</code-php>

==lib/testcases/containerEdit.php==
<code-php>
$TLS_delete = "Удалить";
$TLS_delete_notice = "Внимание: Все связанные результаты прогонов будут удалены";
$TLS_warning_empty_com_name = "Пожалуйста, задайте имя для группы тестов";
</code-php>

==lib/testcases/tcEdit.php==
<code-php>
$TLS_current = "текущий";
$TLS_delete_linked = "Ссылки на планы тестирования будут удалены.";
$TLS_delete_linked_and_exec = "Ссылки на планы тестирования и результаты выполнения будут удалены.";
$TLS_error_tc_add = "При добавлении теста произошла ошибка";
$TLS_title_del_tc = "Удалить тест ";
</code-php>

==lib/usermanagement/rolesview.php==
<code-php>
$TLS_error_role_deletion = "Не удалось удалить роль!";
</code-php>

==lib/usermanagement/usersassign.php==
<code-php>
$TLS_no_test_projects = "Не заведено ни одного проекта";
$TLS_no_test_plans = "Для этого проекта не заведено ни одного плана тестирования";
$TLS_test_project_user_roles_updated = "Пользовательские роли обновлены";
$TLS_test_plan_user_roles_updated = "Пользовательские роли обновлены";
</code-php>

==lib/usermanagement/usersedit.php==
<code-php>
$TLS_user_created="Пользователь %s был успешно создан";
$TLS_user_deleted="Пользователь %s был успешно удален";
$TLS_user_not_added = "Не удалось добавить пользователя!";
</code-php>

==lib/usermanagement/rolesedit.php==
<code-php>
$TLS_error_role_creation = "Не удалось создать роль!";
$TLS_error_role_update = "Не удалось исправить роль!";
</code-php>

==lib/cfields/cfields_edit.php==
<code-php>
$TLS_cf_name_exists = "Пользовательское поле с таким именем уже существует. Пожалуста, выберите другое имя.";
$TLS_error_creating_cf = "Не удалось создать пользовательское поле!";
$TLS_do_update = "исправлено";
$TLS_do_delete = "удалено";
$TLS_do_add = "добавлено";
</code-php>

==resultsBugs.tpl==
<code-php>
$TLS_Open="Открыто";
$TLS_Resolved="Исправленных";
$TLS_Total="Всего";
$TLS_TCs_with_Bugs="Тестов с багами";
</code-php>

TestLink

2007-08-29T14:14:44Z

Andrew: /* Отчет о выполнении требований */

[[Category:TestLink]]

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

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

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

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

== Основные понятия ==
;Тест (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». Например, если тест «1» был успешно пройден в сборке «2», он будет раскрашен в зеленый цвет.

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

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

=== Ввод результатов тестов ===
Страница результатов тестирования показывается справа при выборе в навигационной панели некоторого теста или группы тестов.
На этой странице изображены:
* Заметки по плану тестирования;
* Описание сборки;
* Панель массового управления состоянием тестов;
: служит для массового присвоения одинаковых результатов выполнения всем тестам в наборе(группе)
* История выполнения теста или результаты последнего выполнения;
* Описание теста:
** резюме;
** шаги выполнения;
** ожидаемые результаты.
* Настраиваемые поля;
* Поле для заметок;
* Радиокнопка для выбора результата теста.

Посде того как вы ввели результат выполнения теста, заполнили все пользовательские поля, если это необходимо, и заметки, можно ввести привязку результатов к описанию ошибки (багу) в системе управления ошибками (''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), то появляется этот отчет, показывающий сводную информацию о зарегистрированных багах:

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

== Отчет о выполнении требований ==
Данный отчет для каждой спецификации требований показывает статус требований, на основе данных о результатах выполнения тестов связанных с ними.
Возможны следующие статусы требований:
; Требование выполнено: это означает что все тесты связанные с данным требование выполнены на активной (выбранной с менб справа) сборке выполнены успешно.
: Требование нарушено: есть тесты связанные с требованием и выполненые с результатом «провален».
: Требование заблокировано: есть тесты связанные с требованием и выполненые с результатом «блокирован».
: Требование непроверено: либо нет тестов с вязанных с требование либо все они в статусе «не выполнен».

TestLink

2007-08-29T14:08:44Z

Andrew: /* Всего багов по каждому тесту */

[[Category:TestLink]]

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

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

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

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

== Основные понятия ==
;Тест (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». Например, если тест «1» был успешно пройден в сборке «2», он будет раскрашен в зеленый цвет.

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

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

=== Ввод результатов тестов ===
Страница результатов тестирования показывается справа при выборе в навигационной панели некоторого теста или группы тестов.
На этой странице изображены:
* Заметки по плану тестирования;
* Описание сборки;
* Панель массового управления состоянием тестов;
: служит для массового присвоения одинаковых результатов выполнения всем тестам в наборе(группе)
* История выполнения теста или результаты последнего выполнения;
* Описание теста:
** резюме;
** шаги выполнения;
** ожидаемые результаты.
* Настраиваемые поля;
* Поле для заметок;
* Радиокнопка для выбора результата теста.

Посде того как вы ввели результат выполнения теста, заполнили все пользовательские поля, если это необходимо, и заметки, можно ввести привязку результатов к описанию ошибки (багу) в системе управления ошибками (''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), то появляется этот отчет, показывающий сводную информацию о зарегистрированных багах:

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

== Отчет о выполнении требований ==

TestLink

2007-08-29T13:45:08Z

Andrew: /* Прогон */

[[Category:TestLink]]

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

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

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

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

== Основные понятия ==
;Тест (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». Например, если тест «1» был успешно пройден в сборке «2», он будет раскрашен в зеленый цвет.

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

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

=== Ввод результатов тестов ===
Страница результатов тестирования показывается справа при выборе в навигационной панели некоторого теста или группы тестов.
На этой странице изображены:
* Заметки по плану тестирования;
* Описание сборки;
* Панель массового управления состоянием тестов;
: служит для массового присвоения одинаковых результатов выполнения всем тестам в наборе(группе)
* История выполнения теста или результаты последнего выполнения;
* Описание теста:
** резюме;
** шаги выполнения;
** ожидаемые результаты.
* Настраиваемые поля;
* Поле для заметок;
* Радиокнопка для выбора результата теста.

Посде того как вы ввели результат выполнения теста, заполнили все пользовательские поля, если это необходимо, и заметки, можно ввести привязку результатов к описанию ошибки (багу) в системе управления ошибками (''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]] интегрирован с системой баг-контроля (системой управления ошибками), то появляется этот отчет, показывающий сводную информацию о зарегистрированных багах:

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

== Отчет о выполнении требований ==

TestLink

2007-08-29T12:42:01Z

Andrew: /* Параметры выборки */

[[Category:TestLink]]

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

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

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

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

== Основные понятия ==
;Тест (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». Например, если тест «1» был успешно пройден в сборке «2», он будет раскрашен в зеленый цвет.

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

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

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

= Настраиваемые поля =
Реализация настраиваемых (дополнительных, расширенных, и т. п.) полей, основана на моделях реализации настраиваемых полей в проектах «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]] интегрирован с системой баг-контроля (системой управления ошибками), то появляется этот отчет, показывающий сводную информацию о зарегистрированных багах:

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

== Отчет о выполнении требований ==

TestLink

2007-08-29T12:31:49Z

Andrew: /* Назначение тестов для прогона */

[[Category:TestLink]]

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

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

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

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

== Основные понятия ==
;Тест (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».

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

= Прогон тестов =
== Общая информация ==
Прогон (выполнение) тестов становится возможным, когда:

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

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

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

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

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

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

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

Примеры:

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

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

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

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

= Настраиваемые поля =
Реализация настраиваемых (дополнительных, расширенных, и т. п.) полей, основана на моделях реализации настраиваемых полей в проектах «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]] интегрирован с системой баг-контроля (системой управления ошибками), то появляется этот отчет, показывающий сводную информацию о зарегистрированных багах:

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

== Отчет о выполнении требований ==

TestLink

2007-08-29T11:29:25Z

Andrew: /* Планы тестирования */

[[Category:TestLink]]

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

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

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

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

== Основные понятия ==
;Тест (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».

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

= Прогон тестов =
== Общая информация ==
Прогон (выполнение) тестов становится возможным, когда:

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

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

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

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

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

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

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

Примеры:

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

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

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

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

= Настраиваемые поля =
Реализация настраиваемых (дополнительных, расширенных, и т. п.) полей, основана на моделях реализации настраиваемых полей в проектах «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]] интегрирован с системой баг-контроля (системой управления ошибками), то появляется этот отчет, показывающий сводную информацию о зарегистрированных багах:

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

== Отчет о выполнении требований ==

Strings.txt (TestLink-RU)

2007-08-29T10:33:48Z

Andrew: /* gui/templates/tcDelete.tpl */

[[Category:TestLink]]

Статья с основной локализацией интерфейса. Статья разбита по разделам, в соответствии с разделами в оригинальном файле <tt>strings.txt</tt>. По ссылке «[[#Скачать|скачать]]» можно получить готовый PHP-файл, который нужно разместить в каталоге
testlink\locale\ru_RU\strings.txt

=Скачать=
[{{SERVER}}{{localurl:Special:CisGetPHPPage|pagetitle={{PAGENAMEE}}}} Получить PHP-код]

= Оригинал (наиболее полный английский перевод) =
* http://testlink.cvs.sourceforge.net/testlink/testlink/locale/en_GB/

=Разделы файла strings.txt (ru_RU)=
<code-php>
/**
* TestLink Open Source Project - http://testlink.sourceforge.net/
*
* Filename $RCSfile: strings.txt,v $
*
* @version $Revision$
* @modified $Date$ $Author$
*
* @author Vadim Ivanchenko, Stas Fomin, and russian Testlink community.
* http://lib.custis.ru/index.php/TestLink:_strings.txt_%28RU%29
*
*
**/

$TLS_STRINGFILE_CHARSET = "UTF-8";
</code-php>

==General==
<code-php>
$TLS_asc = "по возрастанию";
$TLS_btn_no = "Нет";
$TLS_create = "Создать";
$TLS_desc = "по убыванию";
$TLS_test_case = "Тест";
$TLS_testcase = $TLS_test_case;
$TLS_test_plan = "План тестирования";
$TLS_testplan = $TLS_test_plan;
$TLS_test_suite = "Группа тестов";
$TLS_SRS = "SRS";
$TLS_Role = "Роль";
$TLS_Keyword = "Ключевое слово";
$TLS_Milestone = "Веха";
$TLS_testsuite_created = "Группа тестов создана";
$TLS_requirement = "Требование";
$TLS_assigned = "назначен";
$TLS_unassigned = "свободен";
$TLS_import_file_type = "Тип импортируемого файла";
$TLS_max_file_size_is = "Макс. размер файла";
$TLS_supported_file_formats = "Поддерживаемые форматы файлов";
</code-php>

==firstLogin.php==
<code-php>
$TLS_cant_create_user = "К сожалению, не удалось создать ваш логин. Пожалуйста, свяжитесь с администратором!";
$TLS_empty_email_address = " Пожалуйста, укажите e-mail!";
$TLS_empty_first_name = " Пожалуйста, укажите имя пользователя.";
$TLS_empty_last_name = " Пожалуйста, укажите фамилию.";
$TLS_fatal_page_title = "TestLink ::: Fatal Error";
$TLS_invalid_user_name = "Некорректный логин пользователя. Пожалуйста, придумайте другой.";
$TLS_passwd_dont_match = "Два введенных пароля не совпадают. Учтите, что пароли чувствительны к регистру, и попробуйте ещё раз.";
$TLS_user_cant_be_created_because = "Не удалось создать ваш аккаунт. Причина:";
$TLS_user_name_exists = "Этот логин пользователя уже используется. Пожалуйста, выберите другой.";
$TLS_valid_user_name_format = "Логин пользователя может состоять только из алфавитно-цифровых символов, пробелов, дефисов и подчеркиваний.";
$TLS_warning_empty_pwd = "Пожалуйста, укажите пароль. Пароль не может быть пустым.";
$TLS_your_info_please = "Введите информацию о пользователе";
</code-php>

==index.php==
<code-php>
$TLS_main_page_title = "TestLink::Главная страница";
</code-php>

==keywordsimport.php==
<code-php>
$TLS_please_choose_keywords_file = "Пожалуйста, выберите файл для загрузки";
$TLS_keywords_file = "Файл с ключевыми словами";
</code-php>

==lostPassword.php==
<code-php>
$TLS_bad_user = "Пользователь не найден, попробуйте еще";
$TLS_contact_admin = "<br> Если проблемы будут продолжаться, пожалуйста, свяжитесь с администратором системы.";
$TLS_mail_empty_address = "Вы не указали email-адреса в вашем профиле! Теперь, чтобы сбросить пароль вам нужно связаться с администратором TestLink-системы.";
$TLS_mail_passwd_subject = "Ваш новый пароль к TestLink'у.";
$TLS_mail_problems = "Ошибка в почтовых настройках, пожалуйста, свяжитесь с администратором.";
$TLS_page_title_lost_passwd = "TestLink - Утерян пароль";
$TLS_your_info_for_passwd = "Заполните информацию о вашем пользователе, и пароль будет вам выслан по почте.";
$TLS_your_password_is = "Ваш пароль к TestLink'у: <br>";
</code-php>

==login.php==
<code-php>
$TLS_bad_user_passwd = "Логин или пароль неверен. Попробуйте ещё!";
$TLS_login_msg_session_exists1 = "Ваша сессия в этом броузере ещё активна. Пожалуйста, используйте ";
$TLS_login_msg_session_exists2 = " если вы хотите обновить вашу сессию.";
$TLS_logout_link = "Выход";
$TLS_passwd_lost = "Ваш пароль выслан вам по email на адрес, который вы указали при регистрации. Проверьте вашу почту. В случае проблем, обратитесь к администратору вашего TestLink'а.";
$TLS_password_reseted="Новый пароль выслан вам по почте";
$TLS_please_login = "Пожалуйста, войдите в систему...";
$TLS_session_expired = "Время ваша сессии окончилось. Пожалуйста, войдите в систему заново.";
$TLS_your_first_login = "Добро пожаловать в TestLink! Сейчас у вас только гостевой доступ. Для большего, нужно войти в систему.";
</code-php>

==planPriority.php==
<code-php>
$TLS_high_priority = "Высокий";
$TLS_low_priority = "Низкий";
$TLS_medium_priority = "Средний";

$TLS_high_risk = "Высокий";
$TLS_low_risk = "Низкий";
$TLS_medium_risk = "Средний";

$TLS_high_importance = "Высокая";
$TLS_low_importance = "Низкая";
$TLS_medium_importance= "Средняя";
</code-php>

==tcEdit.php==
<code-php>
$TLS_tc_created = "Тест %s успешно создан";
$TLS_tc_deleted = "Тест %s успешно удален";
$TLS_tc_updated = "Тест %s отредактирован успешно";
$TLS_tc_update_failed = "Не удалась правка теста %s!";
</code-php>

==gui/templates/attachment404.tpl==
<code-php>
$TLS_btn_close = "Закрыть";
$TLS_error_attachment_not_found = "Ошибка: Вложение не найдено!";
$TLS_title_downloading_attachment = "Загружаем вложение";
</code-php>

==gui/templates/attachmentdelete.tpl==
<code-php>
$TLS_deleting_was_ok = "Вложение удалено.";
$TLS_error_attachment_delete = "При удалении вложения произошла ошибка!";
$TLS_title_delete_attachment = "Удалить вложение";
</code-php>

==gui/templates/containerDelete.tpl==
<code-php>
$TLS_btn_yes_del_comp = "Да, удалить группу тестов";
$TLS_container_title_testsuite =$TLS_test_suite;
$TLS_linked_but_not_executed="Связан с одним или более планом тестирования, но не выполнялась";
$TLS_question_del = "Действительно удалить";
$TLS_th_link_exec_status = "Статус исполнения и связей";
</code-php>

==gui/templates/containerNew.tpl==
<code-php>
$TLS_btn_create_testsuite = "Создать группу тестов";
$TLS_tc_keywords = "Ключевые слова";
$TLS_title_create = "Создать";
$TLS_warning_empty_testsuite_name = "Пожалуйста, задайте имя для группы тестов";
</code-php>

==gui/templates/bug_add.tpl==
<code-php>
$TLS_btn_add_bug = "Добавить баг";
$TLS_bug_id = "Bug id";
$TLS_button_enter_bug = "Создать новый баг";
$TLS_title_bug_add = "Добавить баг";
$TLS_link_bts_create_bug = "Доступ к системе регистрации багов";
</code-php>

==gui/templates/bug_delete.tpl==
<code-php>
$TLS_title_delete_bug = "Удалить баг";
</code-php>

==gui/templates/containerMove.tpl==
<code-php>
$TLS_btn_cp = "Копировать";
$TLS_btn_move = "Переместить";
$TLS_choose_target = "Выберите куда";
$TLS_cont_move_first = "Переместить это";
$TLS_cont_move_second = "в другое";
$TLS_copy_keywords = "Копировать ключевые слова";
$TLS_defined_exclam = "определен !";
$TLS_include_nested = "Включая вложенные данные (только для копирования).";
$TLS_sorry_further = "К сожалению, больше ничего нет ";
$TLS_title_move_cp = "Переместить/Скопировать";
</code-php>

==gui/templates/reqCreate.tpl==
<code-php>
$TLS_btn_cancel = "Отменить";
$TLS_btn_create = "Создать";
$TLS_help = "Помощь";
$TLS_req_create = "Создать требование";
$TLS_req_doc_id = "DOC-ID";
$TLS_req_spec = "Спецификация требований";
$TLS_reqs = "Требования";
$TLS_scope = "Описание";
$TLS_status = "Состояние";
$TLS_title = "Заголовок";
$TLS_warning_empty_req_title = "Заголовок требования должен быть не пуст!";
$TLS_warning_empty_reqdoc_id = "ID документа-требования не должен быть пуст!";
</code-php>

==gui/templates/containerOrder.tpl==
<code-php>
$TLS_btn_upd = "Обновить";
$TLS_no_nodes_to_reorder = "К сожалению, тут нечего упорядочивать.";
$TLS_node = "Имя";
$TLS_th_id = "ID";
$TLS_th_node_type = "Тест / Группа тестов";
$TLS_th_order = "Порядок";
$TLS_title_change_node_order = "Изменить порядок 'потомков'";
$TLS_node_type_dbtable_testsuites=$TLS_test_suite;
$TLS_node_type_dbtable_testcases=$TLS_testcase;
</code-php>

==gui/templates/containerView.tpl==
<code-php>
$TLS_alt_del_com = "Удалить эту группу тестов";
$TLS_alt_edit_com = "Править дату и заголовок для этой группы тестов";
$TLS_alt_move_cp_com = "Переместить или скопировать эту группу тестов в другой проект";
$TLS_btn_del_com = "Удалить";
$TLS_btn_edit_com = "Править";
$TLS_btn_export_all_testsuites = "Экспортировать все группы тестов";
$TLS_btn_export_tc = "Экспортировать Тест(ы)";
$TLS_btn_export_testsuite = "Экспортировать группу тестов";
$TLS_btn_import_tc = "Импортировать Тест(ы)";
$TLS_btn_import_testsuite = "Импортировать группу тестов";
$TLS_btn_move_cp_com = "Переместить/Копировать";
$TLS_btn_new_cat = "Новая группа тестов";
$TLS_btn_new_com = "Новая группа тестов";
$TLS_btn_new_tc = "Создать Тест(ы)";
$TLS_btn_reorder_cat = "Переупорядочить потомков";
$TLS_edit_testproject_basic_data = "Править основные данные проекта";
$TLS_th_notes = "Описание";
$TLS_th_product_name = "Имя проекта";
</code-php>

==gui/templates/cfields_edit.tpl==
<code-php>
$TLS_available_on = "Доступно для";
$TLS_btn_add = "Добавить";
$TLS_btn_delete = "Удалить";
$TLS_btn_ok = "Ok";
$TLS_custom_field = "Пользовательское поле";
$TLS_enable_on_design = "Разрешить при <br>спецификации теста";
$TLS_enable_on_exec = "Разрешить при <br>прогоне теста";
$TLS_label = "Метка";
$TLS_name = "Имя";
$TLS_popup_delete_custom_field = "Вы уверены, что хотите удалить пользовательское поле?";
$TLS_possible_values = "Возможные значения";
$TLS_show_on_design = "Показывать при <br>спецификации теста";
$TLS_show_on_exec = "Показывать при <br>прогоне теста";
$TLS_testcase = $TLS_test_case;
$TLS_title_cfields_mgmt = "Пользовательские поля";
$TLS_type = "Тип";
$TLS_warning_empty_cfield_label = "Пожалуйста, введите метку для этого пользовательского поля.";
$TLS_warning_empty_cfield_name = "Пожалуйста, введите имя этого пользовательского поля.";
</code-php>

==gui/templates/inc_update.tpl==
<code-php>
$TLS_info_failed_db_upd = "Не удалось обновить базу данных!";
$TLS_info_failed_db_upd_details = "Не удалось обновить базу данных! - Подробности:";
$TLS_invalid_query = "Ошибка:";
$TLS_warning = "Предупреждение!!";
$TLS_was_success = " был(и) успешно ";
</code-php>

==gui/templates/execNavigator.tpl==
<code-php>
$TLS_TestPlan = "План тестирования";
$TLS_btn_apply_filter = "Применить фильтр";
$TLS_btn_update_menu = "Обновить меню";
$TLS_caption_nav_filter_settings = "Параметры выборки";
$TLS_current_build = "Текущая сборка";
$TLS_filter_owner = "Ответственный";
$TLS_filter_result = "Результат";
$TLS_filter_tcID = "Фильтр: ID Теста";
$TLS_keyword = "Ключевое слово";
$TLS_test_status_all_status="Все";
</code-php>

==gui/templates/mainPage.tpl==
<code-php>
$TLS_th_my_perc_completed = "У меня выполнено [%]";
$TLS_th_name = "Имя";
$TLS_th_perc_completed = "Выполнено [%]";
$TLS_title_your_tp_metrics = "Ваши метрики для плана тестирования";
</code-php>

==gui/templates/newest_tcversions.tpl==
<code-php>
$TLS_linked_version = "Связанная версия";
$TLS_newest_version = "Самая новая из доступных активных версий";
$TLS_title_newest_tcversions = "Самые новые версии связанных тестов";
</code-php>

==gui/templates/emailSent.tpl==
<code-php>
$TLS_send_test_report = "- Послать Тест-отчёт";
</code-php>

==gui/templates/reqImport.tpl==
<code-php>
$TLS_Result = "Результат";
$TLS_Title = "Заголовок";
$TLS_btn_back2srs = "Назад, к спецификации требований";
$TLS_btn_import = "Импорт";
$TLS_btn_upload_file = "Загрузить файл";
$TLS_check_req_file_structure = "Пожалуйста, проверьте формат файла. Не получается получить из этого файла требования";
$TLS_local_file = "Файл:";
$TLS_max_size_cvs_file1 = "Максимальный размер для этого файла";
$TLS_max_size_cvs_file2 = "kB";
$TLS_req_import_check_note = "Пожалуйста, разрешите возможные конфликты и запустите процесс импорта.";
$TLS_req_import_dont_empty = "Не импортируйте элементы с пустой Сферой";
$TLS_req_import_option_double = "Добавить ещё с тем же заголовком";
$TLS_req_import_option_header = "Разрешить конфликт";
$TLS_req_import_option_overwrite = "Обновить существующий";
$TLS_req_import_option_skip = "Пропускать импорт дублирующих требований";
$TLS_req_import_type = "Тип:";
$TLS_req_msg_norequirement = "Нет требований";
$TLS_required_cvs_format = "Формат файла с требованиями:";
$TLS_title_choose_file_type = "Выберите тип файла";
$TLS_title_choose_local_file = "Выберите файл для загрузки";
$TLS_title_req_import = "Загрузка требований";
$TLS_title_req_import_check_input = "Проверьте импортируемые данные";
</code-php>

==gui/templates/inc_attachments.tpl==
<code-php>
$TLS_alt_delete_build = "Удалить эту сборку";
$TLS_alt_delete_attachment = "Удалить это вложение";
$TLS_attached_files = "Вложенные файлы";
$TLS_attachment_feature_disabled = "вложения отключены";
$TLS_button_upload = "Загрузить";
$TLS_upload_file_new_file = "Загрузить новый файл";
$TLS_warning_delete_attachment = "Действительно удалить вложение?";
</code-php>

==gui/templates/resultsNavigator.tpl==
<code-php>
$TLS_btn_print = "Печать";
$TLS_note_email_sent_t = "Примечание: email format послан на email пользователя";
$TLS_send_results = "Послать отчеты";
$TLS_send_to = "To:";
$TLS_subject = "Subject:";
$TLS_title_active_build = "Активная сборка";
$TLS_title_report_type = "Формат отчета";
$TLS_via_email = "через eMail";
</code-php>

==gui/templates/inc_attachments_upload.tpl==

==gui/templates/cfields_view.tpl==
<code-php>
$TLS_btn_cfields_create = "Создать";
$TLS_manage_cfield = "Управлять пользовательскими полями";
</code-php>

==gui/templates/inc_cat_viewer_ro_m0.tpl==
<code-php>
$TLS_cat_scope = "Описание";
$TLS_category = "Группа тестов";
$TLS_configuration = "Конфигурация";
$TLS_data = "Данные";
$TLS_not_defined = "Не определено.";
$TLS_tools = "Инструменты";
</code-php>

==gui/templates/inc_cat_viewer_rw.tpl==
<code-php>
$TLS_cat_alt_name = "Обязательно заполнить имя группы тестов.";
$TLS_cat_config = "Конфигурация";
$TLS_cat_data = "Данные";
$TLS_cat_name = "Имя группы тестов";
$TLS_cat_tools = "Инструменты";
</code-php>

==gui/templates/reqEdit.tpl==
<code-php>
$TLS_btn_update = "Обновить";
$TLS_by = "by";
$TLS_coverage = "Покрытие";
$TLS_popup_delete_req = "Удалить это требование, Вы уверены?";
$TLS_req_edit = "Править требование";
$TLS_req_msg_notestcase = "Связанных Тестов нет.";
$TLS_requirement_spec = "Спецификация требования";
$TLS_test_case_id = "ID";
$TLS_title_created = "Создано:";
$TLS_title_last_mod = "Последняя правка:";
</code-php>

==gui/templates/buildNew.tpl==
<code-php>
$TLS_active = "Активная";
$TLS_enter_build = "Заголовок";
$TLS_enter_build_notes = "Описание";
$TLS_msg_build = "Замечание: Каждая сборка относится к активному плану тестирования. Описание должно включать: список развертываемых пакетов, утверждений, состояние, и т.п.";
$TLS_open = "Открыть";
$TLS_test_plan = "План тестирования";
$TLS_title_build_2 = "Управление сборками";
$TLS_title_build_create = "Создать новую Сборку";
$TLS_title_build_update = "Править Сборку";
$TLS_warning_empty_build_name = "Пожалуйста, введите имя для этой Сборки!";
</code-php>

==gui/templates/inc_comp_viewer_ro.tpl==
<code-php>
$TLS_component = "Группа тестов";
$TLS_introduction = "Введение";
$TLS_limitations = "Ограничения";
$TLS_methodology = "Методология";
$TLS_references = "Ссылки";
</code-php>

==gui/templates/inc_comp_viewer_rw.tpl==
<code-php>
$TLS_comp_alt_name = "Обязательно введите имя группы тестов.";
$TLS_comp_intro = "Введение";
$TLS_comp_lim = "Ограничения";
$TLS_comp_method = "Методология";
$TLS_comp_name = "Имя группы тестов";
$TLS_comp_ref = "Ссылки";
$TLS_comp_scope = "Описание";
</code-php>

==gui/templates/reqSpecView.tpl==
<code-php>
$TLS_btn_analyse = "Анализировать";
$TLS_btn_check_all = "Проверить все";
$TLS_btn_delete_spec = "Удалить спецификацию";
$TLS_btn_edit_spec = "Править спецификацию";
$TLS_btn_export_reqs = "Экспортировать требования";
$TLS_btn_req_create = "Создать новое требование";
$TLS_btn_spec_list = "Список спецификаций";
$TLS_btn_uncheck_all = "Убрать все отметки";
$TLS_cant_delete_req_nothing_sel = "Пожалуйста, выберите требование!";
$TLS_popup_sure_delete = "Вы уверены удалить эту спецификацию требования?";
$TLS_req_select_create_tc = "Создать Тесты";
$TLS_req_select_delete = "Удалить требования";
$TLS_req_title_list = "Список требований";
$TLS_req_total = "Всего треб.";
$TLS_req_reorder = "Переупорядочить требования?";
$TLS_warning_delete_requirements = "Вы уверены удалить выбранные требования?";
$TLS_title_change_req_order = "Переупорядочивание требований";
</code-php>

==gui/templates/inc_copyrightnotice.tpl==
<code-php>
$TLS_gnu_gpl = "GNU GPL";
$TLS_lic_home = "Домой";
$TLS_lic_product = "TestLink project";
$TLS_licensed_under = "TestLink лицензируется согласно ";
</code-php>

==gui/templates/containerEdit.tpl==
<code-php>
$TLS_btn_update_testsuite = "Обновить группу тестов";
$TLS_title_edit_level = "Править";
</code-php>

==gui/templates/reqSpecAnalyse.tpl==
<code-php>
$TLS_edit = "Править";
$TLS_none = "Пусто ";
$TLS_req = "Требования";
$TLS_req_spec_change = "Изменить спецификацию требований на ";
$TLS_req_title_analyse = "Анализировать спецификацию требований ";
$TLS_req_title_covered = "Покрытые требования";
$TLS_req_title_in_tl = "Требований, зарегистрированных в TestLink";
$TLS_req_title_nottestable = "Нетестируемые требования";
$TLS_req_title_uncovered = "Непокрытые требования";
$TLS_req_title_not_in_tl = "Требований, отсутствующих в TestLink";
$TLS_req_total_count = "Всего требований";
$TLS_testcases = "Тесты";
</code-php>

==gui/templates/reqSpecCreate.tpl==
<code-php>
$TLS_action_create_srs = "Создать спецификацию требований";
$TLS_testproject = "проект";
</code-php>

==gui/templates/inc_reqView.tpl==
<code-php>
$TLS_Author = "Автор";
$TLS_last_edit = "Последняя правка: ";
</code-php>

==gui/templates/inc_res_by_comp.tpl==
<code-php>
$TLS_title_res_by_top_level_suites = "Результаты топовых групп тестов";
$TLS_trep_blocked = "Блокировано";
$TLS_trep_comp = "Группа тестов";
$TLS_trep_comp_perc = "Выполнена [%]";
$TLS_trep_failed = "Сбой";
$TLS_trep_not_run = "Не запускали";
$TLS_trep_passed = "Выполнено";
$TLS_trep_total = "Всего";
</code-php>

==gui/templates/inc_res_by_keyw.tpl==
<code-php>
$TLS_title_res_by_kw = "Результаты по ключевому слову";
$TLS_trep_kw = "Ключевое слово";
</code-php>

==gui/templates/inc_res_by_owner.tpl==
<code-php>
$TLS_title_res_by_owner = "Результаты по Тестировщику";
$TLS_trep_owner = "Тестировщик";
$TLS_title_res_by_tester = "Результаты по Тестировщику";
$TLS_trep_tester = "Тестировщик";
</code-php>

==gui/templates/inc_res_by_prio.tpl==
<code-php>
$TLS_tit_end_date = "Дата окончания";
$TLS_tit_milestone = "Веха";
$TLS_title_res_by_prio = "Результаты по приоритету";
$TLS_trep_milestone_goal = "Цель вехи [%]";
$TLS_trep_prio = "Приоритет";
$TLS_trep_status = "Состояние";
</code-php>

==gui/templates/inc_res_by_ts.tpl==
<code-php>
$TLS_title_res_by_ts = "Результаты по группе тестов";
$TLS_trep_imp = "Важность";
$TLS_trep_risk = "Риск";
$TLS_trep_ts = "Группа тестов";
</code-php>

==gui/templates/reqSpecEdit.tpl==

==gui/templates/inc_show_bug_table.tpl==
<code-php>
$TLS_build = "Сборка";
$TLS_caption_bugtable = "Связанные баги";
$TLS_delete_bug="Удалить баг";
$TLS_del_bug_warning_msg = "Действительно удалить этот баг?";
</code-php>

==gui/templates/reqSpecList.tpl==
<code-php>
$TLS_btn_assign_tc = "Указать Тест";
$TLS_no_docs = "Нет доступных документов.";
$TLS_req_list_docs = "Спецификации требований";
</code-php>

==gui/templates/tcEdit_New_viewer.tpl==
<code-php>
$TLS_alt_add_tc_name = "Обязательно укажите имя Теста.";
$TLS_expected_results = "Ожидаемые результаты";
$TLS_steps = "Шаги";
$TLS_summary = "Резюме";
$TLS_tc_title = "Заголовок Тест-Кейса";
</code-php>

==gui/templates/show_exec_notes.tpl==
<code-php>
$TLS_title_execution_notes = "Замечания по выполнению";
</code-php>

==gui/templates/rolesedit.tpl==
<code-php>
$TLS_btn_create_role = "Создать";
$TLS_btn_edit_role = "Править";
$TLS_caption_define_role = "Определить роль";
$TLS_caption_possible_affected_users = "Возможно влияет на следующих пользователей";
$TLS_enter_role_notes = "Введите описание роли";
$TLS_menu_assign_product_roles = "Укажите роли проекта";
$TLS_menu_assign_testplan_roles = "Укажите роли для плана тестирования";
$TLS_menu_define_roles = "Новая роль";
$TLS_menu_mod_user = "Править пользователя";
$TLS_menu_new_user = "Новый пользователь";
$TLS_menu_edit_user = "Редактировать пользователя";
$TLS_menu_view_users = "Список пользователей";
$TLS_menu_view_roles = "Просмотр ролей";
$TLS_th_cf_rights = "Права на пользовательские поля";
$TLS_th_kw_rights = "Права на ключевые слова";
$TLS_th_mgttc_rights = "Права на управление Тест-Кейсами";
$TLS_th_product_rights = "Права на проект";
$TLS_th_req_rights = "Права на требование";
$TLS_th_rights = "Разрешения";
$TLS_th_rolename = "Роль";
$TLS_th_tp_rights = "Права на план тестирования";
$TLS_th_user_rights = "Права пользователей";
$TLS_title_user_mgmt = "Управление пользователями";
$TLS_warning_modify_role = "Действительно исправить роль?";
</code-php>

==gui/templates/tcSearchForm.tpl==
<code-php>
$TLS_btn_find = "Найти";
$TLS_caption_search_form = "Искать тесты";
$TLS_not_applied = "Не применимо";
$TLS_th_tcid = "ID теста";
$TLS_th_tcversion = "Версия";
$TLS_th_title = "Заголовок";
$TLS_title_search_tcs = "Поиск";
</code-php>

==gui/templates/infoWindow.tpl==

==gui/templates/tcDelete.tpl==
<code-php>
$TLS_btn_yes_iw2del = "Да, удалите тест!";
$TLS_question_del_tc = "Действительно удалить тест?";
$TLS_th_executed = "Выполнено";
$TLS_th_linked_to_tplan = "Связан с планом тестирования";
$TLS_th_version = "Версия";
</code-php>

==gui/templates/tcNew.tpl==
<code-php>
$TLS_title_new_tc = "Создать Тест";
$TLS_warning_empty_tc_title = "Пожалуйста, задайте заголовок для теста";
</code-php>

==gui/templates/tcImport.tpl==
<code-php>
$TLS_title_imp_tc_data = "Импорт данных для теста";
</code-php>

==gui/templates/keywordsimport.tpl==
<code-php>
$TLS_title_keyword_import_to = "Импортировать ключевые слова в ";
$TLS_title_keyword_import = "Импорт ключевых слов";
</code-php>

==gui/templates/keywordsexport.tpl==
<code-php>
$TLS_btn_export = "Экспорт";
$TLS_title_req_import_to = "Импортировать требования в документ:";
</code-php>

==gui/templates/cfields_tproject_assign.tpl==
<code-php>
$TLS_btn_assign = "Привязать";
$TLS_btn_cfields_active_mgmt = "Обновить активное состояние";
$TLS_btn_cfields_display_order = "Сохранить порядок показа";
$TLS_btn_unassign = "Освободить от";
$TLS_cfields_active = "Активный";
$TLS_cfields_tproject_assign = "Привязать пользовательские поля";
$TLS_display_order = "Порядок показа";
$TLS_title_assigned_cfields = "Привязанные пользовательские поля";
$TLS_title_available_cfields = "Доступные пользовательские поля";
</code-php>

==gui/templates/usersview.tpl==
<code-php>
$TLS_No = "Нет";
$TLS_Yes = "Да";
$TLS_alt_delete_user = "Действительно удалить выбранного пользователя?";
$TLS_alt_edit_user = "Править пользователя";
$TLS_order_by_login = "По порядку логинов";
$TLS_order_by_role_descr = "По порядку описания ролей";
$TLS_th_active = "Активный";
$TLS_th_delete = "Удалить?";
$TLS_th_email = "Email";
$TLS_th_first_name = "Имя";
$TLS_th_last_name = "Фамилия";
$TLS_th_locale = "Локализация";
$TLS_th_login = "Логин";
$TLS_th_role = "Роль";
$TLS_warning_delete_user = "Действительно удалить выбранного пользователя?";
</code-php>

==gui/templates/login.tpl==
<code-php>
$TLS_btn_login = "Войти";
$TLS_login_name = "Логин:";
$TLS_lost_password_q = "Забыли пароль?";
$TLS_new_user_q = "Новый пользователь?";
$TLS_password = "Пароль:";
</code-php>

==gui/templates/loginFirst.tpl==
<code-php>
$TLS_btn_add_user_data = "Добавить пользовательские данные";
$TLS_e_mail = "E-mail (нужен, чтобы получить новый пароль):";
$TLS_first_name = "Имя:";
$TLS_last_name = "Фамилия:";
$TLS_link_back_to_login = "Войти еще раз";
$TLS_password_again = "Повторите пароль:";
$TLS_password_mgmt_is_external = "Используется внешнее управление паролями";
</code-php>

==gui/templates/tcMove.tpl==
<code-php>
$TLS_btn_mv = "Переместить";
$TLS_choose_cat = "Выберите группу тестов";
$TLS_inst_move = "Переместить этот тест в другую группу тестов (внутри того же плана тестирования).";
$TLS_title_mv_cp_tc = "Переместить/Копировать Тест";
</code-php>

==gui/templates/loginLost.tpl==
<code-php>
$TLS_btn_send = "Выслать пароль";
$TLS_password_reset = "Сбросить пароль";
</code-php>

==gui/templates/tcView.tpl==
<code-php>
$TLS_no_records_found = "Ничего не найдено.";
</code-php>

==gui/templates/execSetResults.tpl==
<code-php>
$TLS_alt_attachment_mgmt = "вложения";
$TLS_alt_notes = "заметки";
$TLS_attachment_mgmt = "вложения";
$TLS_btn_history_off = "Показывать только последний прогон";
$TLS_btn_history_on = "Показывать полную историю прогонов";
$TLS_btn_save_all_tests_results = "Сохранить все результаты прогонов";
$TLS_btn_save_tc_exec_results = "Сохранить результат прогона";
$TLS_bug_mgmt = "Управление багами";
$TLS_build_is_closed = "Сборка закрыта";
$TLS_builds_notes = "Описание сборки";
$TLS_bulk_tc_status_management = "Массовое управление состоянием Тестов";
$TLS_date_time_run = "Дата";
$TLS_details = "Подробности";
$TLS_exec_notes = "Заметки";
$TLS_exec_status = "Состояние";
$TLS_execution_history = "История прогонов";
$TLS_img_title_bug_mgmt = "Управление багами";
$TLS_img_title_delete_execution= "Удалить прогон";
$TLS_just_last_execution_for_this_build = "Последний прогон для этой сборки";
$TLS_no_data_available = "Данные отсутствуют";
$TLS_set_all_tc_to = "Установить всем состояние ";
$TLS_show_hide = "Показать / скрыть";
$TLS_tc_not_tested_yet = "Еще не протестировано:";
$TLS_test_cases_cannot_be_executed = "Тесты не могут быть выполнены";
$TLS_test_exec_by = "Протестировано: ";
$TLS_test_exec_expected_r = "Ожидаемые результаты";
$TLS_test_exec_last_run_date = "Самые последние запуски:";
$TLS_test_exec_notes = "Заметки / Описание";
$TLS_test_exec_on_build = " в Сборке";
$TLS_test_exec_result = "Результат";
$TLS_test_exec_steps = "Шаги";
$TLS_test_exec_summary = "Резюме";
$TLS_test_plan_notes = "Заметки по плану тестирования";
$TLS_test_status_not_run = "Не запущен";
$TLS_th_test_case_id = "ID ";
$TLS_th_testsuite = "Группа тестов";
$TLS_title_t_r_on_build = "Результы тестов по Сборке";
$TLS_title_t_r_owner = " Ответственный:";
$TLS_title_test_case = "Тест";
$TLS_version = "Версия";
</code-php>

==gui/templates/inc_testsuite_viewer_ro.tpl==
<code-php>
$TLS_keywords = "Ключевые слова";
$TLS_test_suite = "Группа тестов";
</code-php>

==gui/templates/navBar.tpl==
<code-php>
$TLS_home = "Домой";
$TLS_link_logout = "Выход";
$TLS_product = "Проект";
$TLS_product_role = "Роль проекта";
$TLS_title_edit_personal_data = "Мой профиль";
$TLS_title_execute = "Выполнить";
$TLS_title_results = "Отчеты";
$TLS_title_specification = "Спецификация";
</code-php>

==gui/templates/inc_testsuite_viewer_rw.tpl==

==gui/templates/planAddTC_m1.tpl==
<code-php>
$TLS_add_tc = "Добавить";
$TLS_add_remove_selected_tc_hint = "Операция будет выполнена над ВСЕМИ группами тестов";
$TLS_btn_add_remove_selected_tc = "Добавить / Удалить выбранное";
$TLS_btn_add_selected_tc = "Добавить выбранное";
$TLS_btn_check = "Отметить";
$TLS_btn_uncheck = "Снять отметки";
$TLS_check_uncheck_tc = "Все тесты в этой группе тестов.";
$TLS_check_uncheck_all_checkboxes="отметить все/снять все отметки";
$TLS_has_been_executed = "были выполнены";
$TLS_inactive_testcase = "неактивны";
$TLS_no_testcase_available = "Тестов нет";
$TLS_note_keyword_filter = "Тесты фильтруются по ключевому слову";
$TLS_remove_tc = "Удалить";
$TLS_th_test_case = "Тест";
$TLS_title_add_remove_test_to_plan = "Добавить/Удалить Тест(ы) в/из плана тестирования";
$TLS_title_add_test_to_plan = "Добавить Тесты в план тестирования";
$TLS_warning_add_remove_selected_tc = "Вы уверены удалить выбранные Тесты из этого плана тестирования?";
</code-php>

==gui/templates/planAddTCNavigator.tpl==
<code-php>
$TLS_title_navigator = "Навигатор";
</code-php>

==gui/templates/planPriority.tpl==
<code-php>
$TLS_btn_upd_prio = "Сохранить";
$TLS_title_priority = "Определить приоритеты для плана тестирования";
$TLS_tr_th_importance = "Важность";
$TLS_tr_th_prio_cba = "Приоритет (C/B/A)";
$TLS_tr_th_risk = "Риск/Важность";
</code-php>

==gui/templates/planEdit.tpl==
<code-php>
$TLS_btn_testplan_create = "Создать";
$TLS_cancel = "Отменить";
$TLS_opt_no = "Нет";
$TLS_testplan_question_create_tp_from = "Создать из существующего плана тестирования?";
$TLS_testplan_th_active = "Активный";
$TLS_testplan_th_name = "Имя";
$TLS_testplan_th_notes = "Описание";
$TLS_testplan_title_create = "Создать новый план тестирования";
$TLS_testplan_title_edit = "Править план тестирования";
$TLS_testplan_title_for_project = "для проекта: ";
$TLS_testplan_title_tp_management = "Управление планами тестирования";
$TLS_testplan_txt_notes = <<<END
План тестирования должен содержать ясно определенные задачи, включая временные границы.
Он может содержать тест-активность для выпускаемой версии продукта (включая патчи)
или просто единственный запрос от пользователя.<br/>
В описании можно ссылаться на план и другую документацию по проекту.
Разумно перечислить тестируемые возможности, риски и т.п.<br/>
Можно создать новый план тестирования из существующего ("клонировать").
Будут скопированы следующие элементы: Сборки, Тесты, Приоритеты,
Вехи и роли пользователей.<br/>
План тестирования можно деактивировать/заморозить: т.е. запретить любое изменение
атрибутов или вложенных элементов плана тестирования.
Такие планы тестирования будут видны только на странице отчетов и на этой странице.
END;

$TLS_warning_empty_tp_name = "Пожалуйста, введите имя плана тестирования.";
</code-php>

==gui/templates/planNew.tpl==
<code-php>
$TLS_testplan_btn_edit = "Сохранить";
$TLS_testplan_btn_new = "Создать";
$TLS_testplan_menu_create = "Создать";
$TLS_testplan_menu_edit = "Править";
$TLS_testplan_menu_list = "Список";
</code-php>

==gui/templates/planMilestones.tpl==
<code-php>
$TLS_alt_delete_milestone = "Удалить веху?";
$TLS_btn_edit_milestone = "Править";
$TLS_btn_new_milestone = "Создать";
$TLS_info_milestones_date = "Веха не может иметь дату раньше чем 'сегодня'";
$TLS_no_milestones = "Для этого плана тестирования вехи не определены.";
$TLS_popup_delete_milestones = "Вы уверены удалить веху %NAME% ?";
$TLS_warning_empty_milestone_name="Укажите имя вехи!";

$TLS_th_date_format = "Целевая Дата";
$TLS_th_perc_a_prio = "% A-приоритет";
$TLS_th_perc_b_prio = "% B-приоритет";
$TLS_th_perc_c_prio = "% C-приоритет";
$TLS_title_existing_milestones = "Существующие вехи";
$TLS_title_milestones = "Вехи для плана тестирования";
$TLS_title_new_milestone = "Новая Веха";
</code-php>

==gui/templates/projectedit.tpl==
<code-php>
$TLS_btn_activate = "Активировать";
$TLS_btn_del = "Удалить";
$TLS_btn_edit_del = "Править / Удалить";
$TLS_btn_inactivate = "Деактивировать";
$TLS_caption_edit_product = "Править проект";
$TLS_caption_new_product = "Создать проект";
$TLS_color = "Цвет";
$TLS_enable_requirements = "Включить функциональность Требований";
$TLS_info_failed_loc_prod = "Не удалось локализовать проект.";
$TLS_notes = "Заметки";
// Warning!!! - if JS string you must use \\n to get \n
$TLS_popup_product_delete = <<<END
Внимание! Вы собираетесь необратимо удалить все данные связанные проектом:
результаты тестов, планы тестирования, тесты и т.п. \\n
Вместо удаления вы можете деактивировать проект. \\n
Если вы всё-таки настроены удалить проект, рекомендуем вам сначала
сделать бэкап базы данных. \\n
Итак, вы по прежнему уверены удалить проект?
END;
$TLS_warning_empty_tproject_name = "Обязательно задайте имя проекта!";
</code-php>

==gui/templates/reqAssign.tpl==
<code-php>
$TLS_please_select_a_req = "Пожалуйста, выберите требование";
$TLS_req_msg_norequirement66 = "Требования нет";
$TLS_req_title_assign = "Привяжите требования к тесту";
$TLS_req_title_assigned = "Привязанные требования";
$TLS_req_title_unassigned = "Доступные требования";
$TLS_warning_req_tc_assignment_impossible = <<<END
<p>
Вы <b>не можете</b> делать привязку по одной из следующих причин:
<ul>
<li>Не определено ни одной спецификации требования;
<li>Спецификации требований пусты.
</ul>
END;
</code-php>

==gui/templates/tcEdit.tpl==
<code-php>
$TLS_title_edit_tc = "Править Тест";
$TLS_warning_editing_executed_tc = "Внимание: Этот версия теста уже выполнялась";
</code-php>

==gui/templates/planOwner.tpl==
<code-php>
$TLS_assign_ownership = "Назначить ответственного";
$TLS_def_prio_rules = "Определить правила приоритетов";
$TLS_opt_label_none = "нет";
$TLS_th_imp = "Важность";
$TLS_th_owner = "Тестировщик";
$TLS_th_risk = "Риск";
$TLS_th_test_suite = "Группа тестов";
$TLS_title_plan_ownership = "Владелец плана тестирования";
</code-php>

==gui/templates/tcView_viewer.tpl==
<code-php>
$TLS_activate_this_tcversion = "Активировать эту версию";
$TLS_Requirements = "Требования";
$TLS_btn_del_this_version = "Удалить эту версию";
$TLS_btn_edit = "Править";
$TLS_btn_mv_cp = "Переместить/Копировать";
$TLS_btn_new_version = "Создать новую версию";
$TLS_can_not_edit_tc = "Вы не можете редактировать эту версию, т.к. она уже выполнялась";
$TLS_deactivate_this_tcversion = "Деактивировать эту версию";
$TLS_tcversion_is_inactive_msg = "Эта версия <b>неактивна</b>, и не будет доступна для включения в план тестирования";
</code-php>

==gui/templates/planRemoveTC_m1.tpl==
<code-php>
$TLS_btn_remove_selected_tc = "Удалить выбранные тесты tcs";
$TLS_remove_ok = "Удаление прошло успешно ok";
$TLS_title_remove_test_from_plan = "Удалить тест из плана тестирования";
</code-php>

==gui/templates/planTesters.tpl==
<code-php>
$TLS_btn_save = "Сохранить";
</code-php>

==gui/templates/keywordsAssign.tpl==
<code-php>
$TLS_keyword_assignment_empty_tsuite = "В этой группе тестов нет тестов => ключевое слово привязать нельзя";
$TLS_menu_assign_kw_to_tc = "Привязать к тестам";
$TLS_menu_manage_keywords = "Управление ключевыми словами";
$TLS_title_keywords = "Ключевые слова";
</code-php>

==gui/templates/planTestersNavigator.tpl==
<code-php>
$TLS_label_list_of = "Список ";
$TLS_opt_test_plans = "планов тестирования";
$TLS_opt_users = "пользователей";
</code-php>

==gui/templates/planUpdateTC.tpl==
<code-php>
$TLS_btn_upd_ck_tc = "Изменить выбранные тест(ы)";
$TLS_info_all_tc_uptodate = "Все тесты актуальны.";
$TLS_th_category = "Группа тестов";
$TLS_th_component = "Группа тестов";
$TLS_th_id_tc = "[ID] Теста";
$TLS_th_reason = "Причина правки";
$TLS_th_spec_version = "Специальная версия";
$TLS_th_status = "Состояние";
$TLS_th_suite_version = "Версия группы тестов";
$TLS_th_update = "Изменить";
$TLS_title_upd_mod_tc = "Изменить исправленные тесты в ";
</code-php>

==gui/templates/keywordsView.tpl==
<code-php>
$TLS_alt_delete_keyword = "Удалить ключевое слово?";
$TLS_btn_create_keyword = "Создать ключевое слово";
$TLS_btn_edit_keyword = "Править";
$TLS_btn_import_keywords = "Импорт";
$TLS_th_keyword = "Ключевое слово";
$TLS_warning_delete_keyword = "Вы уверены удалить ключевое слово?";
$TLS_warning_enter_at_least1 = "Пожалуйста, введите хотя бы ";
$TLS_warning_enter_at_least2 = " символов.";
$TLS_warning_enter_less1 = "Пожалуйста, используйте не больше чем";
$TLS_warning_enter_less2 = " символов.";
</code-php>

==gui/templates/reqexport.tpl==
<code-php>
$TLS_title_req_export_to = "Экспорт требований";
</code-php>

==gui/templates/resultsAllBuilds.tpl==
<code-php>
$TLS_test_status_blocked = "Блокирован";
$TLS_test_status_failed = "Сбой";
$TLS_test_status_passed = "Пройден";
$TLS_th_build = "Сборка";
$TLS_th_tc_total = "Всего тестов";
</code-php>

==gui/templates/resultsBugs.tpl==
<code-php>
$TLS_date = "Дата:";
$TLS_printed_by = "Напечатано:";
$TLS_title_test_case_bugs = "Баги по тесту";
$TLS_title_test_case_timestamp = "Временная метка теста";
$TLS_title_test_case_title = "Заголовок теста";
$TLS_title_test_suite_name = "Имя группы тестов";
</code-php>

==gui/templates/resultsBuild.tpl==
<code-php>
$TLS_title_met_of_build = "Метрики сборки";
</code-php>

==gui/templates/resultsByStatus.tpl==
<code-php>
$TLS_info_test_results = <<<END
<p>
Показываются результаты только последнего теста.
<p>
В частности, тесты скрыты, если результаты тестов для следующей сборки
имеют статус отличный от "в процессе".
END;

$TLS_th_bugs = "Баги";
$TLS_th_date = "Дата";
$TLS_th_run_by = "Запустил:";
</code-php>

==gui/templates/resultsGeneral.tpl==
<code-php>
$TLS_title_gen_test_rep = "Общие метрики плана тестирования";
</code-php>

==gui/templates/resultsMoreBuilds_query_form.tpl==
<code-php>
$TLS_excel_format = "MS Excel";
$TLS_html_format = "HTML";
$TLS_last_status_any = "Любой";
$TLS_last_status_blocked = "Блокирован";
$TLS_last_status_failed = "Сбой";
$TLS_last_status_not_run = "Не стартовал";
$TLS_last_status_passed = "Пройден";
$TLS_select_builds_header = "Выберите сборку(и)";
$TLS_select_components_header = "Выберите группу тестов";
$TLS_select_keyword_header = "Выберите ключевое слово";
$TLS_select_last_result_header = "Выберите последний результат";
$TLS_select_owner_header = "Выберите владельца";
$TLS_select_report_format_header = "Выберите формат отчета";
$TLS_submit_query = "Выполнить запрос";
$TLS_test_plan_header = "План тестирования: ";
$TLS_query_metrics_report = "Запросить отчет по метрикам";
$TLS_enter_start_time = "Введите начальное время";
$TLS_enter_end_time = "Введите конечное время";
$TLS_year = "год";
$TLS_month = "месяц";
$TLS_day = "день";
$TLS_hour = "час";
$TLS_search_in_notes = "поиск строки в заметках";
$TLS_executor = "исполнитель";
</code-php>

==gui/templates/resultsMoreBuilds_report.tpl==
<code-php>
$TLS_caption_show_collapse = "Показать/Свернуть";
$TLS_caption_user_selected_query_parameters = "Параметры запроса";
$TLS_not_yet_executed = "Еще не выполнялся";
$TLS_show_hide_all = "Показать/Скрыть все";
$TLS_th_builds = "Сборка(и)";
$TLS_th_execution_ts = "Время";
$TLS_th_last_result = "Последний результат";
$TLS_th_report_format = "Тип отчета";
$TLS_th_test_plan = "План тестирования";
$TLS_th_test_suites = "Группа(ы) тестов";
$TLS_th_tester_id = "Тестировщик";
$TLS_th_total_block = "# блокированных ";
$TLS_th_total_cases = "# тестов";
$TLS_th_total_fail = "# сбоев";
$TLS_th_total_not_run = "# не стартовавших";
$TLS_th_total_pass = "# выполненных";
$TLS_th_start_time = "Время начала";
$TLS_th_end_time = "Время окончания";
$TLS_th_executor = "Исполнитель";
$TLS_th_search_notes_string = "в заметках искать строку";
$TLS_true = "да";
$TLS_false = "нет";
$TLS_display_suite_summaries = "Показать итоги по группе тестов";
$TLS_display_query_params = "Показать параметры запроса";
$TLS_display_totals = "Показать суммарную информацию";
</code-php>

==gui/templates/resultsReqs.tpl==
<code-php>
$TLS_req_title_blocked = "Заблокировано требований";
$TLS_req_title_failed = "Нарушено требований";
$TLS_req_title_notrun = "Непроверенных требований";
$TLS_req_title_passed = "Выполнено требований";
$TLS_title_result_req_testplan = "Результаты тестов основанных на спецификации требований";
$TLS_title_test_plan = "План тестирования";
</code-php>

==gui/templates/resultsSend.tpl==
<code-php>
$TLS_btn_send_report = "Послать отчет";
$TLS_check_send_to_me = "Послать отчет самому себе";
$TLS_mail_body = "Тело письма:";
$TLS_mail_report = "Отчет:";
$TLS_mail_subject = "Тема письма:";
$TLS_mail_to = "Кому:";
$TLS_status_for_build = "Состояние сборки";
$TLS_tp_status = "Общее состояние плана тестирования";
$TLS_tp_status_for_build = "Состояние плана тестирования для сборки";
</code-php>

==gui/templates/resultsTC.tpl==
<code-php>
$TLS_generated_by_TestLink_on="Сформировано системой TestLink, ";
</code-php>

==gui/templates/tcEdit_m2.tpl==

==gui/templates/tcPrintNavigator.tpl==
<code-php>
$TLS_caption_print_opt = "Настройки печати";
$TLS_tr_td_show_as = "Показать как";
</code-php>

==gui/templates/tcReorder.tpl==
<code-php>
$TLS_no_tc_to_reorder = "Нет тестов для переупорядочивания.";
$TLS_title_change_tc_order = "Изменить порядок тестов в этой группе тестов.";
</code-php>

==gui/templates/tcTree.tpl==
<code-php>
$TLS_button_refresh = "Обновить";
$TLS_button_update_tree = "Обновить дерево";
$TLS_do_auto_update = "Обновлять дерево после каждой операции";
$TLS_no_tc_spec_av = "Нет тест-спецификаций.";
</code-php>

==gui/templates/tc_exec_assignment.tpl==
<code-php>
$TLS_btn_do = "Пуск";
$TLS_btn_update_selected_tc = "Изменить выбранные тесты";
$TLS_title_tc_exec_assignment = "Назначить прогоны тестов для плана тестирования ";
$TLS_user = "Пользователь";
$TLS_user_bulk_assignment = "Массовое назначение ответственных пользователей";
</code-php>

==gui/templates/testSetNavigator.tpl==

==gui/templates/userInfo.tpl==
<code-php>
$TLS_btn_change_passwd = "Сменить пароль";
$TLS_btn_upd_user_data = "Изменить";
$TLS_th_new_passwd = "Новый пароль";
$TLS_th_new_passwd_again = "Повторите новый пароль";
$TLS_th_old_passwd = "Старый пароль";
$TLS_title_account_settings = "Настройки профиля";
$TLS_title_change_your_passwd = "Сменить ваш пароль";
$TLS_warning_different_pwd = "Пожалуйста, повторите еще раз ваш новый пароль. Введенные пароли не совпадают.";
$TLS_warning_empty_pwd = "Пароль должен быть не пуст!";
$TLS_your_password_is_external = "Ваш пароль ведётся во внешней системе";
</code-php>

==gui/templates/usersassign.tpl==
<code-php>
$TLS_TestProject = "проект";
$TLS_User = "Пользователь";
$TLS_btn_change = "Изменить";
$TLS_caption_assign_testplan_user_roles = "Назначить роли плана тестирования пользователям";
$TLS_caption_assign_testproject_user_roles = "Назначить роли проекта пользователям";
$TLS_menu_assign_testproject_roles = "Назначить роли проекта";
$TLS_th_roles = "Роли";
$TLS_title_assign_roles = "Назначить роли";
</code-php>

==gui/templates/usersedit.tpl==
<code-php>
$TLS_button_reset_password = "Сбросить пароль";
$TLS_caption_user_details = "Свойства пользователя";
$TLS_th_password = "Пароль";
$TLS_warning_empty_first_name = "Пожалуста, введите имя";
$TLS_warning_empty_last_name = "Пожалуйста, введите фамилию";
$TLS_warning_empty_login = "Пожалуйста, введите логин";
</code-php>

==gui/templates/attachmentupload.tpl==
<code-php>
$TLS_attachment_upload_ok="Файл загружен.";
$TLS_enter_attachment_title = "Введите заголовок для этого вложения.";
$TLS_import_was_ok = "Импорт прошел успешно.";
$TLS_max_size_cvs_file = "Максимальный размер файла:";
$TLS_title_upload_attachment = "Загрузить вложение";
</code-php>

==gui/templates/rolesview.tpl==
<code-php>
$TLS_N_A = "N/A";
$TLS_alt_delete_role = "Удалить роль";
$TLS_alt_edit_role = "Править роль";
$TLS_btn_confirm_delete = "Удалить";
$TLS_no_roles = "Нет ролей";
$TLS_title_roles = "Доступные роли";
$TLS_warning_users_will_be_reset = "'Задетым пользователям' будет назначена гостевая роль!";
</code-php>

==gui/templates/tcexport.tpl==
<code-php>
$TLS_export_with_keywords = "Экспортировать с ключевыми словами";
</code-php>

==gui/templates/buildView.tpl==
<code-php>
$TLS_alt_active_build = "Активная сборка";
$TLS_alt_edit_build = "Редактировать эту сборку";
$TLS_alt_open_build = "Открыть сборку";
$TLS_btn_build_create = "Создать";
$TLS_no_builds = "В этот плане тестирования сборок не определено.";
$TLS_th_description = "Описание";
$TLS_th_open = "Открыть";
$TLS_title_build_list = "Список существующих сборок";
$TLS_warning_delete_build = <<<END
<p>Вы действительно хотите уничтожить эту сборку? <p>
Все связанные данные (в частности, результаты тестов) будут также удалены!";
END;
</code-php>

==gui/templates/planView.tpl==
<code-php>
$TLS_testplan_alt_delete_tp = "Удалить этот план тестирования?";
$TLS_testplan_alt_edit_tp = "Править план тестирования";
$TLS_testplan_msg_delete_confirm = <<<END
Вы уверены, что хотите удалить план тестирования? <p>
План тестирования можно деактивировать не удаляя.
END;

$TLS_testplan_th_delete = "Удалить";
$TLS_testplan_title_list = "Список планов тестирования";
$TLS_testplan_txt_empty_list = <<<END
Ни одного плана тестирования не определено! <p>
Чтобы воспользоваться функциональностью прогонов тестов, нужно
создать хотя бы один.
END;
$TLS_alt_active_testplan = "Активный план тестирования";
</code-php>

==gui/templates/mainPage_left.tpl==
<code-php>
$TLS_href_assign_user_roles = "Назначить пользовательские роли";
$TLS_href_browse_tc = "Просмотр тестов";
$TLS_href_cfields_management = "Управление пользовательскими полями";
$TLS_href_cfields_tproject_assign = "Привязка пользовательских полей";
$TLS_href_create_product = "Создать новый проект";
$TLS_href_edit_product = "Править/Удалить проект";
$TLS_href_edit_tc = "Редактировать тесты";
$TLS_href_keywords_assign = "Привязать ключевые слова";
$TLS_href_keywords_manage = "Управление ключевыми словами";
$TLS_href_keywords_view = "Просмотр ключевых слов";
$TLS_href_print_tc = "Печать тестов";
$TLS_href_req_assign = "Привязать требования";
$TLS_href_req_spec = "Спецификация требований";
$TLS_href_roles_management = "Управление ролями";
$TLS_href_search_tc = "Искать тест(ы)";
$TLS_href_user_management = "Управление пользователями";
$TLS_title_requirements = "Требования";
$TLS_title_test_spec = "Спецификации тестов";
$TLS_title_product_mgmt = "Управление проектами";
</code-php>

==gui/templates/mainPage_right.tpl==
<code-php>
$TLS_filter_tp_by_product = "Фильтровать план тестирования по проектам";
$TLS_href_add_test_case = "Добавить тест(ы)";
$TLS_href_build_new = "Управление сборками";
$TLS_href_execute_test = "Выполнить тесты";
$TLS_href_plan_assign_priority = "Установить приоритеты";
$TLS_href_plan_define_priority = "Определить правила приоритетов";
$TLS_href_plan_management = "Управление планами тестирования";
$TLS_href_plan_mstones = "Управление вехами";
$TLS_href_print_tc_suite = "Печать плана тестирования";
$TLS_href_remove_test_case = "Удалить Тест(ы)";
$TLS_href_rep_and_metrics = "Отчеты и метрики";
$TLS_href_tc_exec_assignment = "Поручить прогон тестов";
$TLS_href_upd_mod_tc = "Сохранить измененные тесты";
$TLS_msg_no_rights_for_tp = "- недоступен (У вас нет доступа ни для одного плана тестирования)";
$TLS_testplan_role = "Роль плана тестирования";
$TLS_title_test_case_suite = "Содержание плана тестирования";
$TLS_title_test_execution = "Выполнение плана тестирования";
$TLS_title_test_plan_mgmt = "Управление планами тестирования";
$TLS_href_newest_tcversions = "Показать тесты с самыми свежими версиями";
</code-php>

==lib/execute/bug_add.php==
<code-php>
$TLS_bug_added = "Баг добавлен";
$TLS_error_bug_does_not_exist_on_bts="Бага с таким ID не зарегистрировано в BTS!";
$TLS_error_wrong_BugID_format = "Неверный формат BugID!";
</code-php>

==lib/execute/bug_delete.php==
<code-php>
$TLS_bugdeleting_was_ok = "Баг успешно удален.";
</code-php>

==lib/functions/doAuthorize.php==
<code-php>
$TLS_error_ldap_auth_failed = "LDAP-аутентификация не удалась";
$TLS_error_ldap_bind_failed = "Не удалось выполнить LDAP-binding";
$TLS_error_ldap_server_connect_failed = "Не удалось соединится с LDAP-сервером";
$TLS_error_ldap_update_failed = "Обновление LDAP не удалось";
$TLS_error_ldap_user_not_found = "LDAP-пользователь не найден";
</code-php>

==lib/functions/product.inc.php==
<code-php>
$TLS_info_product_delete_fails = "При удалении этого проекта произошла ошибка";
</code-php>

==lib/functions/results.inc.php==
<code-php>
$TLS_trep_failing = "Провалены";
$TLS_trep_passing = "Прошли";
$TLS_trep_status_for_build = "Состояние для сборки";
$TLS_trep_status_for_ts = "Состояние для группы тестов";
$TLS_unassigned = "Не назначены";
</code-php>

==lib/functions/resultsMoreBuilds.inc.php==
<code-php>
$TLS_bugs = "Связанные Баги";
$TLS_builds_selected = "Сборка(и)";
$TLS_case_not_run_warning = "Тест не запущен";
$TLS_category_header = "Группа тестов =";
$TLS_daterun = "Дата запуска";
$TLS_last_status = "Последнее состояние";
$TLS_number_blocked = "# блокированных";
$TLS_number_cases = "# тестов";
$TLS_number_executions = "# тест-пусков";
$TLS_number_failed = "# тест-сбоев";
$TLS_number_not_run = "# не запущено";
$TLS_number_passed = "# пройденных";
$TLS_owner = "Тестировщик";
$TLS_owner_header = "Tester =";
$TLS_runby = "Запущен тестировщиком ";
$TLS_test_plan_name = "План тестирования";
</code-php>

==lib/functions/roles.inc.php==
<code-php>
$TLS_desc_cfield_management = "Управление пользовательскими полями";
$TLS_desc_cfield_view = "Просмотр пользовательских полей (read-only)";
$TLS_desc_mgt_modify_key = "Управление ключевыми словами";
$TLS_desc_mgt_modify_product= "Управление проектами";
$TLS_desc_mgt_modify_req = "Управление требованиями";
$TLS_desc_mgt_modify_tc = "Создание/правка тестов";
$TLS_desc_mgt_modify_users = "Управление пользователями";
$TLS_desc_mgt_view_key = "Просмотр ключевых слов (read-only)";
$TLS_desc_mgt_view_req = "Просмотр требований (read-only)";
$TLS_desc_mgt_view_tc = "Просмотр Тестов (read-only)";
$TLS_desc_role_management = "Управление ролями";
$TLS_desc_testplan_create_build = "Создание/редактирование сборки";
$TLS_desc_testplan_execute = "Выполнение плана тестирования";
$TLS_desc_testplan_metrics = "Метрики плана тестирования";
$TLS_desc_testplan_planning = "Составление плана тестирования";
$TLS_desc_user_role_assignment = "Назначение ролей";
$TLS_error_duplicate_rolename = "Роль с таким именем уже есть!";
$TLS_error_role_no_rights = "Вы не можете создать роль без каких-либо прав!";
$TLS_error_role_no_rolename = "Вам нужно ввести имя для этой роли.";
$TLS_mgt_testplan_create = "Создать/править план тестирования";
</code-php>

==lib/functions/testproject.class.php==
<code-php>
$TLS_error_creating_req_spec = "Ошибка при создании спецификации требования";
$TLS_info_product_name_empty = "Нельзя давать пустое имя.";
$TLS_keyword_already_exists = "Такое ключевое слово уже есть";
$TLS_string_contains_bad_chars = "Введенная строка содержит недопустимые символы.";
$TLS_warning_duplicate_req_title= "Требование с таким заголовком уже есть.";
</code-php>

==lib/functions/requirements.inc.php==
<code-php>
$TLS_conflict = "Конфликт";
$TLS_error_deleting_req = "Ошибка при удалении требования(й).";
$TLS_error_inserting_req = "Ошибка при вставке требования(й).";
$TLS_error_updating_req = "Ошибка при правке требования(й).";
$TLS_error_updating_reqspec = "Ошибка при правке спецификаций требований.";
$TLS_file_is_not_xml = "Файл не распознан как корректный XML, и не может быть использован.";
$TLS_ok = "OK";
$TLS_req_import_format_description1 = " - тип CSV требует три поля на каждую запись: 'req_doc_id','title','description'";
$TLS_req_import_format_description2 = " - CSV, экспортированный из DOORS требует запись-заголовок.";
$TLS_req_import_result_overwritten = "перезаписано!";
$TLS_req_import_result_skipped = "пропущено";
$TLS_req_state_not_testable = "не тестируемо";
$TLS_req_state_valid = "актуально";
$TLS_the_format_req_xml_import = "Неверный XML-формат для импорта требований";
$TLS_warning_duplicate_reqdoc_id = "Не уникальный (дублирующий) id документа";
</code-php>

==lib/functions/testsuite.class.php==
<code-php>
$TLS_component_name_already_exists = "Группа тестов с таким именем уже зарегистрирована";
$TLS_testsuite = "Группа тестов";
</code-php>

==lib/functions/exec.inc.php==
<code-php>
$TLS_test_results_submitted = "Результаты тестов отправлены.";
</code-php>

==lib/functions/print.inc.php==
<code-php>
$TLS_author = "Автор";
$TLS_printed_by_TestLink_on = "Распечатано TestLink'ом ";
$TLS_title_toc = "Содержание";
$TLS_passfail = "Пройден / Провален";
$TLS_testnotes = "Заметки к тесту";
</code-php>

==lib/functions/testcase.class.php==
<code-php>
$TLS_testcase_name_already_exists = "Тест с таким именем уже есть!";
$TLS_the_format_tc_xml_import = "";
</code-php>

==lib/functions/info.inc.php==
<code-php>
$TLS_email_sent_message = "Ваше письмо отослано.";
</code-php>

==lib/functions/users.inc.php==
<code-php>
$TLS_Unknown = "Неизвестно";
$TLS_duplicate_login = "Пользователь с таким логином уже есть!";
$TLS_login_must_not_be_empty = "Логин не должен быть пустым!";
$TLS_wrong_old_password = "Старый пароль неверен!";
</code-php>

==lib/functions/email_api.php==
<code-php>
$TLS_stmp_host_unconfigured = "Некорректно указан SMTP host!";
</code-php>

==lib/functions/common.php==

==lib/functions/configCheck.php==
<code-php>
$TLS_attachments_dir = "каталог для вложений:";
$TLS_bts_connection_problems = <<<END
Не удалось соединиться с вашей Bug Tracking System.<p>
Пожалуйста, проверьте настройки.<p>
Будьте внимательны, эта проблема
снижает производительность TestLink'а.
END;

$TLS_but_directory_is_not_writable = "Каталог закрыт для записи!";
$TLS_directory_is_writable = "Каталог открыт для записи.";
$TLS_does_not_exist = "не существует";
$TLS_exists = "существует";
$TLS_ldap_extension_not_loaded=<<<END
Метод аутентификации указан как LDAP </br>
однако PHP/LDAP extension не загружено =>
Вам не удастся войти в систему.
Пожалуйста, свяжитесь с администратором TestLink'а.
END;
$TLS_sec_note_admin_default_pwd = "Вам необходимо сменить пароль по умолчанию у пользователя 'admin'!";
$TLS_sec_note_remove_install_dir = "Инсталляционный каталог должен быть удален!";
</code-php>

==lib/general/frmWorkArea.php==
<code-php>
$TLS_create_a_build = "Создать новую сборку";
$TLS_no_build_warning_part1 = "Ни одной сборки для этого тест плана не создано.";
$TLS_no_build_warning_part2 = "Создайте их или попросите об этом свое руководство.";
</code-php>

==lib/general/myTPInfo.php==
<code-php>
$TLS_no_testplans_available = "К сожалению, ни одного плана тестирования не доступно";
</code-php>

==lib/general/tlsmarty.inc.php==

==lib/keywords/keywords.inc.php==
<code-php>
$TLS_empty_keyword_no = "Ключевое слово должно быть непустым!";
$TLS_keywords_char_not_allowed = "Запятые и кавычки недопустимы в ключевых словах!";
$TLS_tc_kw_update_fails1 = "Тест";
$TLS_tc_kw_update_fails2 = " дал сбой ";
$TLS_the_format_keyword_csv_import = "keyword;notes";
$TLS_the_format_keyword_xml_import = "<keywords><keyword name=\"name\">Notes</keyword></keywords>";
</code-php>

==lib/keywords/keywordsView.php==
<code-php>
$TLS_kw_delete_fails = "Не удалось удаление ключевого слова!";
$TLS_kw_update_fails = "Не удалась правка ключевого слова!";
</code-php>

==lib/keywords/keywordsAssign.php==
<code-php>
$TLS_assigned_kword = "Связанные ключевые слова";
$TLS_available_kword = "Доступные ключевые слова";
</code-php>

==lib/plan/buildNew.php==
<code-php>
$TLS_cannot_add_build = "Невозможно добавить сборку!";
$TLS_cannot_delete_build = "Невозможно удалить сборку!";
$TLS_cannot_update_build = "Ошибка при правке сборки!";
$TLS_warning_duplicate_build = "Сборка с таким идентификатором уже есть.";
</code-php>

==lib/plan/plan.inc.php==
<code-php>
$TLS_warning_empty_milestone_name = "Обязательно введите имя для вехи!";
$TLS_warning_enter_valid_date = "Введенная дата некорректна!";
$TLS_warning_invalid_percentage_value = "Значения-проценты должны быть от 0 to 100 (%)";
$TLS_warning_milestone_date = "Веха не может иметь дату раньше чем 'сегодня'!";
$TLS_warning_percentage_value_higher_than_100 = "Сумма всех значений-процентов не должна быть больше 100!";
</code-php>

==lib/plan/planMilestones.php==
<code-php>
$TLS_milestone_delete_fails = "Не удалось удалить веху!";
$TLS_warning_milestone_add_failed = "Не удалось добавить веху!";
$TLS_warning_milestone_update_failed = "Не удалось править веху!";
</code-php>

==lib/plan/planOwner.php==
<code-php>
$TLS_opt_imp_high = "Высокая";
$TLS_opt_imp_low = "Низкая";
$TLS_opt_imp_medium = "Средняя";
</code-php>

==lib/plan/planTestersEdit.php==
<code-php>
$TLS_title_assign_tp = "Поручить планы тестирования пользователю: ";
$TLS_title_assign_users = "Назначить пользователей на план тестирования: ";
</code-php>

==lib/plan/planTestersNavigator.php==
<code-php>
$TLS_nav_test_plan = "Навигатор - Планы тестирования";
$TLS_nav_users = "Навигатор - Пользователи";
</code-php>

==lib/plan/planUpdateTC.php==
<code-php>
$TLS_category_has_changed = "Группа тестов изменена";
$TLS_component_has_changed = "Группа тестов изменена";
$TLS_deleted = "удалена";
$TLS_different_versions = "Различные версии";
$TLS_plan_update_no_tc_updated = "Ни один тест не изменен";
$TLS_planupdate_tc_deleted1 = "Тест";
$TLS_planupdate_tc_deleted2 = "был удален.";
$TLS_planupdate_tc_updated1 = "Тест";
$TLS_planupdate_tc_updated2 = "был изменен.";
$TLS_tcorder_has_changed = "Порядок тестов был изменен";
$TLS_updated = "изменен";
</code-php>

==lib/plan/testSetNavigator.php==
<code-php>
$TLS_title_test_plan_navigator = "Навигация по планам тестирования";
</code-php>

==lib/plan/testSetRemove.php==
<code-php>
$TLS_tcase_removed_from_tplan="тест удален из плана тестирования";
$TLS_multiple_tcase_removed_from_tplan="Тесты удалены из плана тестирования";
</code-php>

==lib/plan/planEdit.php==
<code-php>
$TLS_testplan_created_ok = "План тестирования был создан";
$TLS_update_tp_failed1 = "Правка плана тестирования '";
$TLS_update_tp_failed2 = "' не удалась";
$TLS_warning_duplicate_tplan_name = "План тестирования с таким именем уже есть. Выберите другое имя!";
</code-php>

==lib/print/selectData.php==
<code-php>
$TLS_opt_show_doc_header = "Показать заголовок документа";
$TLS_opt_show_tc_body = "Показать тело теста";
$TLS_opt_show_tc_summary = "Показать резюме теста";
$TLS_opt_show_toc = "Показать Содержание";
$TLS_opt_show_tc_author = "Показать автора теста";
$TLS_opt_show_passfail = "Показать статус «пройден/провален» и заметки";
$TLS_title_tc_print_navigator = "Навигация - Печать спецификации тестов";
$TLS_title_tp_print_navigator = "Навигация - Печать плана тестирования";
</code-php>

==lib/project/projectedit.php==
<code-php>
$TLS_error_product_name_duplicate = "Уже есть проект с именем %s. <br>Пожалуйста, выберите другое имя";
$TLS_info_no_more_prods = "проектов больше нет.";
$TLS_info_product_activated = "проект активирован.";
$TLS_info_product_inactivated = "проект деактивирован.";
$TLS_info_product_not_deleted_check_log = "Не удалось удалить проект. Проверьте лог TestLink'а.";
$TLS_info_product_was_deleted = "проект успешно удален.";
$TLS_refer_to_log = " Пожалуйста, изучите лог TestLink'а для дополнительной информации.";
$TLS_test_project_activated = "проект %s успешно активирован";
$TLS_test_project_created = "проект %s успешно создан";
$TLS_test_project_deleted = "проект %s успешно удален";
$TLS_test_project_inactivated = "проект %s успешно деактивирован";
$TLS_test_project_updated = "проект %s успешно отредактирован";
$TLS_test_project_update_failed = "Правка проекта %s не удалась!";
</code-php>

==lib/results/charts.php==
<code-php>
$TLS_maani_copyright = "flash technology предоставлена http://www.maani.us";
$TLS_graphical_reports = "Графические отчеты";
$TLS_overall_metrics = "Общие метрики";
$TLS_results_by_keyword = "Результаты по ключевому слову";
$TLS_results_by_tester = "Рузультаты по тестировщику";
$TLS_results_top_level_suites = "Результаты по топ группам тестов";
</code-php>

==lib/req/reqImport.php==
<code-php>
$TLS_file_is_not_ok_for_import_type = "Кажется тип файла не совпадает с выбранным для импорта типом";
$TLS_file_is_not_text = "Это не текстовый файл. Использовать нельзя.";
$TLS_please_choose_req_file = "Пожалуйста, выберите файл для загрузки";
$TLS_req_import_finished = "Импорт завершен!";
</code-php>

==lib/req/reqSpecView.php==
<code-php>
$TLS_cant_create_tc_from_req_nothing_sel = "Пожалуйста, выберите требование!";
$TLS_req_created = "Требование %s успешно создано.";
</code-php>

==lib/req/reqTcAssign.php==
<code-php>
$TLS_req_msg_noselect = "Ничего не выбрано";
$TLS_req_msg_notupdated_coverage = "Покрытие не обновлено для Требований: ";
</code-php>

==lib/results/resultsBugs.php==
<code-php>
$TLS_title_test_report_all_builds = "Отчет: Результаты тестов для всех сборок";
</code-php>

==lib/results/resultsAllBuilds.php==
<code-php>
$TLS_title_metrics_x_build = " - Результаты тестов. Метрики X Сборки";
</code-php>

==lib/results/resultsByStatus.php==
<code-php>
$TLS_list_of_blocked = "Список блокированных тестов";
$TLS_list_of_failed = "Список проваленных тестов";
$TLS_list_of_not_run = "Список незапущенных тестов";
</code-php>

==lib/results/resultsTC.php==

==lib/results/resultsNavigator.php==
<code-php>
$TLS_link_charts="Диаграммы";
$TLS_link_report_blocked_tcs = "Блокированные тесты";
$TLS_link_report_failed = "Проваленные тесты";
$TLS_link_report_general_tp_metrics = "Общие метрики плана тестирования";
$TLS_link_report_metrics_active_build = "Метрики активной сборки";
$TLS_link_report_metrics_more_builds = "Запрос метрик";
$TLS_link_report_not_run="Не запущенные тесты";
$TLS_link_report_overall_build = "Общий статус сборки";
$TLS_link_report_reqs_coverage = "Отчет о выполнении требований";
$TLS_link_report_test = "Отчет по тестам";
$TLS_link_report_total_bugs = "Всего багов по каждому тесту";
</code-php>

==lib/results/resultsSend.php==
<code-php>
$TLS_send_to_empty_email_warning = "Пожалуйста, введите правильный email.";
$TLS_warning_create_build_first = "Сначала Вы должны создать или импортировать сборки.";
</code-php>

==lib/results/displayMgr.php==
<code-php>
$TLS_error_sendreport_no_email_credentials = "Email для этого пользователя не указан, пожалуйста, укажите его в настройках своего профиля";
</code-php>

==lib/testcases/archive.inc.php==

==lib/testcases/listTestCases.php==

==lib/testcases/tcImport.php==
<code-php>
$TLS_please_choose_file_to_import = "Пожалуйста, выберите файл для импорта";
$TLS_title_tc_import_to = "Импорт Тестов";
$TLS_title_tsuite_import_to = "Импорт группы тестов";
$TLS_wrong_xml_tcase_file = "Некорректный XML в файле с тестами";
$TLS_wrong_xml_tsuite_file = "Некорректный XML в файле с группой тестов";
</code-php>

==lib/testcases/tcexport.php==
<code-php>
$TLS_no_testcases_to_export = "Нет тестов для экспорта";
$TLS_no_testsuites_to_export = "Нет группы тестов для экспорта";
$TLS_title_tc_export = "Экспорт теста";
$TLS_title_tc_export_all = "Экспортировать все тесты";
$TLS_title_tsuite_export = "Экспортировать все группы тестов";
$TLS_title_tsuite_export_all = "Экспортировать все группы тестов";
</code-php>

==lib/testcases/containerEdit.php==
<code-php>
$TLS_delete = "Удалить";
$TLS_delete_notice = "Внимание: Все связанные результаты прогонов будут удалены";
$TLS_warning_empty_com_name = "Пожалуйста, задайте имя для группы тестов";
</code-php>

==lib/testcases/tcEdit.php==
<code-php>
$TLS_current = "текущий";
$TLS_delete_linked = "Ссылки на планы тестирования будут удалены.";
$TLS_delete_linked_and_exec = "Ссылки на планы тестирования и результаты выполнения будут удалены.";
$TLS_error_tc_add = "При добавлении теста произошла ошибка";
$TLS_title_del_tc = "Удалить тест ";
</code-php>

==lib/usermanagement/rolesview.php==
<code-php>
$TLS_error_role_deletion = "Не удалось удалить роль!";
</code-php>

==lib/usermanagement/usersassign.php==
<code-php>
$TLS_no_test_projects = "Не заведено ни одного проекта";
$TLS_no_test_plans = "Для этого проекта не заведено ни одного плана тестирования";
$TLS_test_project_user_roles_updated = "Пользовательские роли обновлены";
$TLS_test_plan_user_roles_updated = "Пользовательские роли обновлены";
</code-php>

==lib/usermanagement/usersedit.php==
<code-php>
$TLS_user_created="Пользователь %s был успешно создан";
$TLS_user_deleted="Пользователь %s был успешно удален";
$TLS_user_not_added = "Не удалось добавить пользователя!";
</code-php>

==lib/usermanagement/rolesedit.php==
<code-php>
$TLS_error_role_creation = "Не удалось создать роль!";
$TLS_error_role_update = "Не удалось исправить роль!";
</code-php>

==lib/cfields/cfields_edit.php==
<code-php>
$TLS_cf_name_exists = "Пользовательское поле с таким именем уже существует. Пожалуста, выберите другое имя.";
$TLS_error_creating_cf = "Не удалось создать пользовательское поле!";
$TLS_do_update = "исправлено";
$TLS_do_delete = "удалено";
$TLS_do_add = "добавлено";
</code-php>

==resultsBugs.tpl==
<code-php>
$TLS_Open="Открыто";
$TLS_Resolved="Исправленных";
$TLS_Total="Всего";
$TLS_TCs_with_Bugs="Тестов с багами";
</code-php>

Strings.txt (TestLink-RU)

2007-08-29T10:33:23Z

Andrew: /* gui/templates/tcDelete.tpl */

[[Category:TestLink]]

Статья с основной локализацией интерфейса. Статья разбита по разделам, в соответствии с разделами в оригинальном файле <tt>strings.txt</tt>. По ссылке «[[#Скачать|скачать]]» можно получить готовый PHP-файл, который нужно разместить в каталоге
testlink\locale\ru_RU\strings.txt

=Скачать=
[{{SERVER}}{{localurl:Special:CisGetPHPPage|pagetitle={{PAGENAMEE}}}} Получить PHP-код]

= Оригинал (наиболее полный английский перевод) =
* http://testlink.cvs.sourceforge.net/testlink/testlink/locale/en_GB/

=Разделы файла strings.txt (ru_RU)=
<code-php>
/**
* TestLink Open Source Project - http://testlink.sourceforge.net/
*
* Filename $RCSfile: strings.txt,v $
*
* @version $Revision$
* @modified $Date$ $Author$
*
* @author Vadim Ivanchenko, Stas Fomin, and russian Testlink community.
* http://lib.custis.ru/index.php/TestLink:_strings.txt_%28RU%29
*
*
**/

$TLS_STRINGFILE_CHARSET = "UTF-8";
</code-php>

==General==
<code-php>
$TLS_asc = "по возрастанию";
$TLS_btn_no = "Нет";
$TLS_create = "Создать";
$TLS_desc = "по убыванию";
$TLS_test_case = "Тест";
$TLS_testcase = $TLS_test_case;
$TLS_test_plan = "План тестирования";
$TLS_testplan = $TLS_test_plan;
$TLS_test_suite = "Группа тестов";
$TLS_SRS = "SRS";
$TLS_Role = "Роль";
$TLS_Keyword = "Ключевое слово";
$TLS_Milestone = "Веха";
$TLS_testsuite_created = "Группа тестов создана";
$TLS_requirement = "Требование";
$TLS_assigned = "назначен";
$TLS_unassigned = "свободен";
$TLS_import_file_type = "Тип импортируемого файла";
$TLS_max_file_size_is = "Макс. размер файла";
$TLS_supported_file_formats = "Поддерживаемые форматы файлов";
</code-php>

==firstLogin.php==
<code-php>
$TLS_cant_create_user = "К сожалению, не удалось создать ваш логин. Пожалуйста, свяжитесь с администратором!";
$TLS_empty_email_address = " Пожалуйста, укажите e-mail!";
$TLS_empty_first_name = " Пожалуйста, укажите имя пользователя.";
$TLS_empty_last_name = " Пожалуйста, укажите фамилию.";
$TLS_fatal_page_title = "TestLink ::: Fatal Error";
$TLS_invalid_user_name = "Некорректный логин пользователя. Пожалуйста, придумайте другой.";
$TLS_passwd_dont_match = "Два введенных пароля не совпадают. Учтите, что пароли чувствительны к регистру, и попробуйте ещё раз.";
$TLS_user_cant_be_created_because = "Не удалось создать ваш аккаунт. Причина:";
$TLS_user_name_exists = "Этот логин пользователя уже используется. Пожалуйста, выберите другой.";
$TLS_valid_user_name_format = "Логин пользователя может состоять только из алфавитно-цифровых символов, пробелов, дефисов и подчеркиваний.";
$TLS_warning_empty_pwd = "Пожалуйста, укажите пароль. Пароль не может быть пустым.";
$TLS_your_info_please = "Введите информацию о пользователе";
</code-php>

==index.php==
<code-php>
$TLS_main_page_title = "TestLink::Главная страница";
</code-php>

==keywordsimport.php==
<code-php>
$TLS_please_choose_keywords_file = "Пожалуйста, выберите файл для загрузки";
$TLS_keywords_file = "Файл с ключевыми словами";
</code-php>

==lostPassword.php==
<code-php>
$TLS_bad_user = "Пользователь не найден, попробуйте еще";
$TLS_contact_admin = "<br> Если проблемы будут продолжаться, пожалуйста, свяжитесь с администратором системы.";
$TLS_mail_empty_address = "Вы не указали email-адреса в вашем профиле! Теперь, чтобы сбросить пароль вам нужно связаться с администратором TestLink-системы.";
$TLS_mail_passwd_subject = "Ваш новый пароль к TestLink'у.";
$TLS_mail_problems = "Ошибка в почтовых настройках, пожалуйста, свяжитесь с администратором.";
$TLS_page_title_lost_passwd = "TestLink - Утерян пароль";
$TLS_your_info_for_passwd = "Заполните информацию о вашем пользователе, и пароль будет вам выслан по почте.";
$TLS_your_password_is = "Ваш пароль к TestLink'у: <br>";
</code-php>

==login.php==
<code-php>
$TLS_bad_user_passwd = "Логин или пароль неверен. Попробуйте ещё!";
$TLS_login_msg_session_exists1 = "Ваша сессия в этом броузере ещё активна. Пожалуйста, используйте ";
$TLS_login_msg_session_exists2 = " если вы хотите обновить вашу сессию.";
$TLS_logout_link = "Выход";
$TLS_passwd_lost = "Ваш пароль выслан вам по email на адрес, который вы указали при регистрации. Проверьте вашу почту. В случае проблем, обратитесь к администратору вашего TestLink'а.";
$TLS_password_reseted="Новый пароль выслан вам по почте";
$TLS_please_login = "Пожалуйста, войдите в систему...";
$TLS_session_expired = "Время ваша сессии окончилось. Пожалуйста, войдите в систему заново.";
$TLS_your_first_login = "Добро пожаловать в TestLink! Сейчас у вас только гостевой доступ. Для большего, нужно войти в систему.";
</code-php>

==planPriority.php==
<code-php>
$TLS_high_priority = "Высокий";
$TLS_low_priority = "Низкий";
$TLS_medium_priority = "Средний";

$TLS_high_risk = "Высокий";
$TLS_low_risk = "Низкий";
$TLS_medium_risk = "Средний";

$TLS_high_importance = "Высокая";
$TLS_low_importance = "Низкая";
$TLS_medium_importance= "Средняя";
</code-php>

==tcEdit.php==
<code-php>
$TLS_tc_created = "Тест %s успешно создан";
$TLS_tc_deleted = "Тест %s успешно удален";
$TLS_tc_updated = "Тест %s отредактирован успешно";
$TLS_tc_update_failed = "Не удалась правка теста %s!";
</code-php>

==gui/templates/attachment404.tpl==
<code-php>
$TLS_btn_close = "Закрыть";
$TLS_error_attachment_not_found = "Ошибка: Вложение не найдено!";
$TLS_title_downloading_attachment = "Загружаем вложение";
</code-php>

==gui/templates/attachmentdelete.tpl==
<code-php>
$TLS_deleting_was_ok = "Вложение удалено.";
$TLS_error_attachment_delete = "При удалении вложения произошла ошибка!";
$TLS_title_delete_attachment = "Удалить вложение";
</code-php>

==gui/templates/containerDelete.tpl==
<code-php>
$TLS_btn_yes_del_comp = "Да, удалить группу тестов";
$TLS_container_title_testsuite =$TLS_test_suite;
$TLS_linked_but_not_executed="Связан с одним или более планом тестирования, но не выполнялась";
$TLS_question_del = "Действительно удалить";
$TLS_th_link_exec_status = "Статус исполнения и связей";
</code-php>

==gui/templates/containerNew.tpl==
<code-php>
$TLS_btn_create_testsuite = "Создать группу тестов";
$TLS_tc_keywords = "Ключевые слова";
$TLS_title_create = "Создать";
$TLS_warning_empty_testsuite_name = "Пожалуйста, задайте имя для группы тестов";
</code-php>

==gui/templates/bug_add.tpl==
<code-php>
$TLS_btn_add_bug = "Добавить баг";
$TLS_bug_id = "Bug id";
$TLS_button_enter_bug = "Создать новый баг";
$TLS_title_bug_add = "Добавить баг";
$TLS_link_bts_create_bug = "Доступ к системе регистрации багов";
</code-php>

==gui/templates/bug_delete.tpl==
<code-php>
$TLS_title_delete_bug = "Удалить баг";
</code-php>

==gui/templates/containerMove.tpl==
<code-php>
$TLS_btn_cp = "Копировать";
$TLS_btn_move = "Переместить";
$TLS_choose_target = "Выберите куда";
$TLS_cont_move_first = "Переместить это";
$TLS_cont_move_second = "в другое";
$TLS_copy_keywords = "Копировать ключевые слова";
$TLS_defined_exclam = "определен !";
$TLS_include_nested = "Включая вложенные данные (только для копирования).";
$TLS_sorry_further = "К сожалению, больше ничего нет ";
$TLS_title_move_cp = "Переместить/Скопировать";
</code-php>

==gui/templates/reqCreate.tpl==
<code-php>
$TLS_btn_cancel = "Отменить";
$TLS_btn_create = "Создать";
$TLS_help = "Помощь";
$TLS_req_create = "Создать требование";
$TLS_req_doc_id = "DOC-ID";
$TLS_req_spec = "Спецификация требований";
$TLS_reqs = "Требования";
$TLS_scope = "Описание";
$TLS_status = "Состояние";
$TLS_title = "Заголовок";
$TLS_warning_empty_req_title = "Заголовок требования должен быть не пуст!";
$TLS_warning_empty_reqdoc_id = "ID документа-требования не должен быть пуст!";
</code-php>

==gui/templates/containerOrder.tpl==
<code-php>
$TLS_btn_upd = "Обновить";
$TLS_no_nodes_to_reorder = "К сожалению, тут нечего упорядочивать.";
$TLS_node = "Имя";
$TLS_th_id = "ID";
$TLS_th_node_type = "Тест / Группа тестов";
$TLS_th_order = "Порядок";
$TLS_title_change_node_order = "Изменить порядок 'потомков'";
$TLS_node_type_dbtable_testsuites=$TLS_test_suite;
$TLS_node_type_dbtable_testcases=$TLS_testcase;
</code-php>

==gui/templates/containerView.tpl==
<code-php>
$TLS_alt_del_com = "Удалить эту группу тестов";
$TLS_alt_edit_com = "Править дату и заголовок для этой группы тестов";
$TLS_alt_move_cp_com = "Переместить или скопировать эту группу тестов в другой проект";
$TLS_btn_del_com = "Удалить";
$TLS_btn_edit_com = "Править";
$TLS_btn_export_all_testsuites = "Экспортировать все группы тестов";
$TLS_btn_export_tc = "Экспортировать Тест(ы)";
$TLS_btn_export_testsuite = "Экспортировать группу тестов";
$TLS_btn_import_tc = "Импортировать Тест(ы)";
$TLS_btn_import_testsuite = "Импортировать группу тестов";
$TLS_btn_move_cp_com = "Переместить/Копировать";
$TLS_btn_new_cat = "Новая группа тестов";
$TLS_btn_new_com = "Новая группа тестов";
$TLS_btn_new_tc = "Создать Тест(ы)";
$TLS_btn_reorder_cat = "Переупорядочить потомков";
$TLS_edit_testproject_basic_data = "Править основные данные проекта";
$TLS_th_notes = "Описание";
$TLS_th_product_name = "Имя проекта";
</code-php>

==gui/templates/cfields_edit.tpl==
<code-php>
$TLS_available_on = "Доступно для";
$TLS_btn_add = "Добавить";
$TLS_btn_delete = "Удалить";
$TLS_btn_ok = "Ok";
$TLS_custom_field = "Пользовательское поле";
$TLS_enable_on_design = "Разрешить при <br>спецификации теста";
$TLS_enable_on_exec = "Разрешить при <br>прогоне теста";
$TLS_label = "Метка";
$TLS_name = "Имя";
$TLS_popup_delete_custom_field = "Вы уверены, что хотите удалить пользовательское поле?";
$TLS_possible_values = "Возможные значения";
$TLS_show_on_design = "Показывать при <br>спецификации теста";
$TLS_show_on_exec = "Показывать при <br>прогоне теста";
$TLS_testcase = $TLS_test_case;
$TLS_title_cfields_mgmt = "Пользовательские поля";
$TLS_type = "Тип";
$TLS_warning_empty_cfield_label = "Пожалуйста, введите метку для этого пользовательского поля.";
$TLS_warning_empty_cfield_name = "Пожалуйста, введите имя этого пользовательского поля.";
</code-php>

==gui/templates/inc_update.tpl==
<code-php>
$TLS_info_failed_db_upd = "Не удалось обновить базу данных!";
$TLS_info_failed_db_upd_details = "Не удалось обновить базу данных! - Подробности:";
$TLS_invalid_query = "Ошибка:";
$TLS_warning = "Предупреждение!!";
$TLS_was_success = " был(и) успешно ";
</code-php>

==gui/templates/execNavigator.tpl==
<code-php>
$TLS_TestPlan = "План тестирования";
$TLS_btn_apply_filter = "Применить фильтр";
$TLS_btn_update_menu = "Обновить меню";
$TLS_caption_nav_filter_settings = "Параметры выборки";
$TLS_current_build = "Текущая сборка";
$TLS_filter_owner = "Ответственный";
$TLS_filter_result = "Результат";
$TLS_filter_tcID = "Фильтр: ID Теста";
$TLS_keyword = "Ключевое слово";
$TLS_test_status_all_status="Все";
</code-php>

==gui/templates/mainPage.tpl==
<code-php>
$TLS_th_my_perc_completed = "У меня выполнено [%]";
$TLS_th_name = "Имя";
$TLS_th_perc_completed = "Выполнено [%]";
$TLS_title_your_tp_metrics = "Ваши метрики для плана тестирования";
</code-php>

==gui/templates/newest_tcversions.tpl==
<code-php>
$TLS_linked_version = "Связанная версия";
$TLS_newest_version = "Самая новая из доступных активных версий";
$TLS_title_newest_tcversions = "Самые новые версии связанных тестов";
</code-php>

==gui/templates/emailSent.tpl==
<code-php>
$TLS_send_test_report = "- Послать Тест-отчёт";
</code-php>

==gui/templates/reqImport.tpl==
<code-php>
$TLS_Result = "Результат";
$TLS_Title = "Заголовок";
$TLS_btn_back2srs = "Назад, к спецификации требований";
$TLS_btn_import = "Импорт";
$TLS_btn_upload_file = "Загрузить файл";
$TLS_check_req_file_structure = "Пожалуйста, проверьте формат файла. Не получается получить из этого файла требования";
$TLS_local_file = "Файл:";
$TLS_max_size_cvs_file1 = "Максимальный размер для этого файла";
$TLS_max_size_cvs_file2 = "kB";
$TLS_req_import_check_note = "Пожалуйста, разрешите возможные конфликты и запустите процесс импорта.";
$TLS_req_import_dont_empty = "Не импортируйте элементы с пустой Сферой";
$TLS_req_import_option_double = "Добавить ещё с тем же заголовком";
$TLS_req_import_option_header = "Разрешить конфликт";
$TLS_req_import_option_overwrite = "Обновить существующий";
$TLS_req_import_option_skip = "Пропускать импорт дублирующих требований";
$TLS_req_import_type = "Тип:";
$TLS_req_msg_norequirement = "Нет требований";
$TLS_required_cvs_format = "Формат файла с требованиями:";
$TLS_title_choose_file_type = "Выберите тип файла";
$TLS_title_choose_local_file = "Выберите файл для загрузки";
$TLS_title_req_import = "Загрузка требований";
$TLS_title_req_import_check_input = "Проверьте импортируемые данные";
</code-php>

==gui/templates/inc_attachments.tpl==
<code-php>
$TLS_alt_delete_build = "Удалить эту сборку";
$TLS_alt_delete_attachment = "Удалить это вложение";
$TLS_attached_files = "Вложенные файлы";
$TLS_attachment_feature_disabled = "вложения отключены";
$TLS_button_upload = "Загрузить";
$TLS_upload_file_new_file = "Загрузить новый файл";
$TLS_warning_delete_attachment = "Действительно удалить вложение?";
</code-php>

==gui/templates/resultsNavigator.tpl==
<code-php>
$TLS_btn_print = "Печать";
$TLS_note_email_sent_t = "Примечание: email format послан на email пользователя";
$TLS_send_results = "Послать отчеты";
$TLS_send_to = "To:";
$TLS_subject = "Subject:";
$TLS_title_active_build = "Активная сборка";
$TLS_title_report_type = "Формат отчета";
$TLS_via_email = "через eMail";
</code-php>

==gui/templates/inc_attachments_upload.tpl==

==gui/templates/cfields_view.tpl==
<code-php>
$TLS_btn_cfields_create = "Создать";
$TLS_manage_cfield = "Управлять пользовательскими полями";
</code-php>

==gui/templates/inc_cat_viewer_ro_m0.tpl==
<code-php>
$TLS_cat_scope = "Описание";
$TLS_category = "Группа тестов";
$TLS_configuration = "Конфигурация";
$TLS_data = "Данные";
$TLS_not_defined = "Не определено.";
$TLS_tools = "Инструменты";
</code-php>

==gui/templates/inc_cat_viewer_rw.tpl==
<code-php>
$TLS_cat_alt_name = "Обязательно заполнить имя группы тестов.";
$TLS_cat_config = "Конфигурация";
$TLS_cat_data = "Данные";
$TLS_cat_name = "Имя группы тестов";
$TLS_cat_tools = "Инструменты";
</code-php>

==gui/templates/reqEdit.tpl==
<code-php>
$TLS_btn_update = "Обновить";
$TLS_by = "by";
$TLS_coverage = "Покрытие";
$TLS_popup_delete_req = "Удалить это требование, Вы уверены?";
$TLS_req_edit = "Править требование";
$TLS_req_msg_notestcase = "Связанных Тестов нет.";
$TLS_requirement_spec = "Спецификация требования";
$TLS_test_case_id = "ID";
$TLS_title_created = "Создано:";
$TLS_title_last_mod = "Последняя правка:";
</code-php>

==gui/templates/buildNew.tpl==
<code-php>
$TLS_active = "Активная";
$TLS_enter_build = "Заголовок";
$TLS_enter_build_notes = "Описание";
$TLS_msg_build = "Замечание: Каждая сборка относится к активному плану тестирования. Описание должно включать: список развертываемых пакетов, утверждений, состояние, и т.п.";
$TLS_open = "Открыть";
$TLS_test_plan = "План тестирования";
$TLS_title_build_2 = "Управление сборками";
$TLS_title_build_create = "Создать новую Сборку";
$TLS_title_build_update = "Править Сборку";
$TLS_warning_empty_build_name = "Пожалуйста, введите имя для этой Сборки!";
</code-php>

==gui/templates/inc_comp_viewer_ro.tpl==
<code-php>
$TLS_component = "Группа тестов";
$TLS_introduction = "Введение";
$TLS_limitations = "Ограничения";
$TLS_methodology = "Методология";
$TLS_references = "Ссылки";
</code-php>

==gui/templates/inc_comp_viewer_rw.tpl==
<code-php>
$TLS_comp_alt_name = "Обязательно введите имя группы тестов.";
$TLS_comp_intro = "Введение";
$TLS_comp_lim = "Ограничения";
$TLS_comp_method = "Методология";
$TLS_comp_name = "Имя группы тестов";
$TLS_comp_ref = "Ссылки";
$TLS_comp_scope = "Описание";
</code-php>

==gui/templates/reqSpecView.tpl==
<code-php>
$TLS_btn_analyse = "Анализировать";
$TLS_btn_check_all = "Проверить все";
$TLS_btn_delete_spec = "Удалить спецификацию";
$TLS_btn_edit_spec = "Править спецификацию";
$TLS_btn_export_reqs = "Экспортировать требования";
$TLS_btn_req_create = "Создать новое требование";
$TLS_btn_spec_list = "Список спецификаций";
$TLS_btn_uncheck_all = "Убрать все отметки";
$TLS_cant_delete_req_nothing_sel = "Пожалуйста, выберите требование!";
$TLS_popup_sure_delete = "Вы уверены удалить эту спецификацию требования?";
$TLS_req_select_create_tc = "Создать Тесты";
$TLS_req_select_delete = "Удалить требования";
$TLS_req_title_list = "Список требований";
$TLS_req_total = "Всего треб.";
$TLS_req_reorder = "Переупорядочить требования?";
$TLS_warning_delete_requirements = "Вы уверены удалить выбранные требования?";
$TLS_title_change_req_order = "Переупорядочивание требований";
</code-php>

==gui/templates/inc_copyrightnotice.tpl==
<code-php>
$TLS_gnu_gpl = "GNU GPL";
$TLS_lic_home = "Домой";
$TLS_lic_product = "TestLink project";
$TLS_licensed_under = "TestLink лицензируется согласно ";
</code-php>

==gui/templates/containerEdit.tpl==
<code-php>
$TLS_btn_update_testsuite = "Обновить группу тестов";
$TLS_title_edit_level = "Править";
</code-php>

==gui/templates/reqSpecAnalyse.tpl==
<code-php>
$TLS_edit = "Править";
$TLS_none = "Пусто ";
$TLS_req = "Требования";
$TLS_req_spec_change = "Изменить спецификацию требований на ";
$TLS_req_title_analyse = "Анализировать спецификацию требований ";
$TLS_req_title_covered = "Покрытые требования";
$TLS_req_title_in_tl = "Требований, зарегистрированных в TestLink";
$TLS_req_title_nottestable = "Нетестируемые требования";
$TLS_req_title_uncovered = "Непокрытые требования";
$TLS_req_title_not_in_tl = "Требований, отсутствующих в TestLink";
$TLS_req_total_count = "Всего требований";
$TLS_testcases = "Тесты";
</code-php>

==gui/templates/reqSpecCreate.tpl==
<code-php>
$TLS_action_create_srs = "Создать спецификацию требований";
$TLS_testproject = "проект";
</code-php>

==gui/templates/inc_reqView.tpl==
<code-php>
$TLS_Author = "Автор";
$TLS_last_edit = "Последняя правка: ";
</code-php>

==gui/templates/inc_res_by_comp.tpl==
<code-php>
$TLS_title_res_by_top_level_suites = "Результаты топовых групп тестов";
$TLS_trep_blocked = "Блокировано";
$TLS_trep_comp = "Группа тестов";
$TLS_trep_comp_perc = "Выполнена [%]";
$TLS_trep_failed = "Сбой";
$TLS_trep_not_run = "Не запускали";
$TLS_trep_passed = "Выполнено";
$TLS_trep_total = "Всего";
</code-php>

==gui/templates/inc_res_by_keyw.tpl==
<code-php>
$TLS_title_res_by_kw = "Результаты по ключевому слову";
$TLS_trep_kw = "Ключевое слово";
</code-php>

==gui/templates/inc_res_by_owner.tpl==
<code-php>
$TLS_title_res_by_owner = "Результаты по Тестировщику";
$TLS_trep_owner = "Тестировщик";
$TLS_title_res_by_tester = "Результаты по Тестировщику";
$TLS_trep_tester = "Тестировщик";
</code-php>

==gui/templates/inc_res_by_prio.tpl==
<code-php>
$TLS_tit_end_date = "Дата окончания";
$TLS_tit_milestone = "Веха";
$TLS_title_res_by_prio = "Результаты по приоритету";
$TLS_trep_milestone_goal = "Цель вехи [%]";
$TLS_trep_prio = "Приоритет";
$TLS_trep_status = "Состояние";
</code-php>

==gui/templates/inc_res_by_ts.tpl==
<code-php>
$TLS_title_res_by_ts = "Результаты по группе тестов";
$TLS_trep_imp = "Важность";
$TLS_trep_risk = "Риск";
$TLS_trep_ts = "Группа тестов";
</code-php>

==gui/templates/reqSpecEdit.tpl==

==gui/templates/inc_show_bug_table.tpl==
<code-php>
$TLS_build = "Сборка";
$TLS_caption_bugtable = "Связанные баги";
$TLS_delete_bug="Удалить баг";
$TLS_del_bug_warning_msg = "Действительно удалить этот баг?";
</code-php>

==gui/templates/reqSpecList.tpl==
<code-php>
$TLS_btn_assign_tc = "Указать Тест";
$TLS_no_docs = "Нет доступных документов.";
$TLS_req_list_docs = "Спецификации требований";
</code-php>

==gui/templates/tcEdit_New_viewer.tpl==
<code-php>
$TLS_alt_add_tc_name = "Обязательно укажите имя Теста.";
$TLS_expected_results = "Ожидаемые результаты";
$TLS_steps = "Шаги";
$TLS_summary = "Резюме";
$TLS_tc_title = "Заголовок Тест-Кейса";
</code-php>

==gui/templates/show_exec_notes.tpl==
<code-php>
$TLS_title_execution_notes = "Замечания по выполнению";
</code-php>

==gui/templates/rolesedit.tpl==
<code-php>
$TLS_btn_create_role = "Создать";
$TLS_btn_edit_role = "Править";
$TLS_caption_define_role = "Определить роль";
$TLS_caption_possible_affected_users = "Возможно влияет на следующих пользователей";
$TLS_enter_role_notes = "Введите описание роли";
$TLS_menu_assign_product_roles = "Укажите роли проекта";
$TLS_menu_assign_testplan_roles = "Укажите роли для плана тестирования";
$TLS_menu_define_roles = "Новая роль";
$TLS_menu_mod_user = "Править пользователя";
$TLS_menu_new_user = "Новый пользователь";
$TLS_menu_edit_user = "Редактировать пользователя";
$TLS_menu_view_users = "Список пользователей";
$TLS_menu_view_roles = "Просмотр ролей";
$TLS_th_cf_rights = "Права на пользовательские поля";
$TLS_th_kw_rights = "Права на ключевые слова";
$TLS_th_mgttc_rights = "Права на управление Тест-Кейсами";
$TLS_th_product_rights = "Права на проект";
$TLS_th_req_rights = "Права на требование";
$TLS_th_rights = "Разрешения";
$TLS_th_rolename = "Роль";
$TLS_th_tp_rights = "Права на план тестирования";
$TLS_th_user_rights = "Права пользователей";
$TLS_title_user_mgmt = "Управление пользователями";
$TLS_warning_modify_role = "Действительно исправить роль?";
</code-php>

==gui/templates/tcSearchForm.tpl==
<code-php>
$TLS_btn_find = "Найти";
$TLS_caption_search_form = "Искать тесты";
$TLS_not_applied = "Не применимо";
$TLS_th_tcid = "ID теста";
$TLS_th_tcversion = "Версия";
$TLS_th_title = "Заголовок";
$TLS_title_search_tcs = "Поиск";
</code-php>

==gui/templates/infoWindow.tpl==

==gui/templates/tcDelete.tpl==
<code-php>
$TLS_btn_yes_iw2del = "Да, удалите Тест!";
$TLS_question_del_tc = "Действительно удалить тест?";
$TLS_th_executed = "Выполнено";
$TLS_th_linked_to_tplan = "Связан с планом тестирования";
$TLS_th_version = "Версия";
</code-php>

==gui/templates/tcNew.tpl==
<code-php>
$TLS_title_new_tc = "Создать Тест";
$TLS_warning_empty_tc_title = "Пожалуйста, задайте заголовок для теста";
</code-php>

==gui/templates/tcImport.tpl==
<code-php>
$TLS_title_imp_tc_data = "Импорт данных для теста";
</code-php>

==gui/templates/keywordsimport.tpl==
<code-php>
$TLS_title_keyword_import_to = "Импортировать ключевые слова в ";
$TLS_title_keyword_import = "Импорт ключевых слов";
</code-php>

==gui/templates/keywordsexport.tpl==
<code-php>
$TLS_btn_export = "Экспорт";
$TLS_title_req_import_to = "Импортировать требования в документ:";
</code-php>

==gui/templates/cfields_tproject_assign.tpl==
<code-php>
$TLS_btn_assign = "Привязать";
$TLS_btn_cfields_active_mgmt = "Обновить активное состояние";
$TLS_btn_cfields_display_order = "Сохранить порядок показа";
$TLS_btn_unassign = "Освободить от";
$TLS_cfields_active = "Активный";
$TLS_cfields_tproject_assign = "Привязать пользовательские поля";
$TLS_display_order = "Порядок показа";
$TLS_title_assigned_cfields = "Привязанные пользовательские поля";
$TLS_title_available_cfields = "Доступные пользовательские поля";
</code-php>

==gui/templates/usersview.tpl==
<code-php>
$TLS_No = "Нет";
$TLS_Yes = "Да";
$TLS_alt_delete_user = "Действительно удалить выбранного пользователя?";
$TLS_alt_edit_user = "Править пользователя";
$TLS_order_by_login = "По порядку логинов";
$TLS_order_by_role_descr = "По порядку описания ролей";
$TLS_th_active = "Активный";
$TLS_th_delete = "Удалить?";
$TLS_th_email = "Email";
$TLS_th_first_name = "Имя";
$TLS_th_last_name = "Фамилия";
$TLS_th_locale = "Локализация";
$TLS_th_login = "Логин";
$TLS_th_role = "Роль";
$TLS_warning_delete_user = "Действительно удалить выбранного пользователя?";
</code-php>

==gui/templates/login.tpl==
<code-php>
$TLS_btn_login = "Войти";
$TLS_login_name = "Логин:";
$TLS_lost_password_q = "Забыли пароль?";
$TLS_new_user_q = "Новый пользователь?";
$TLS_password = "Пароль:";
</code-php>

==gui/templates/loginFirst.tpl==
<code-php>
$TLS_btn_add_user_data = "Добавить пользовательские данные";
$TLS_e_mail = "E-mail (нужен, чтобы получить новый пароль):";
$TLS_first_name = "Имя:";
$TLS_last_name = "Фамилия:";
$TLS_link_back_to_login = "Войти еще раз";
$TLS_password_again = "Повторите пароль:";
$TLS_password_mgmt_is_external = "Используется внешнее управление паролями";
</code-php>

==gui/templates/tcMove.tpl==
<code-php>
$TLS_btn_mv = "Переместить";
$TLS_choose_cat = "Выберите группу тестов";
$TLS_inst_move = "Переместить этот тест в другую группу тестов (внутри того же плана тестирования).";
$TLS_title_mv_cp_tc = "Переместить/Копировать Тест";
</code-php>

==gui/templates/loginLost.tpl==
<code-php>
$TLS_btn_send = "Выслать пароль";
$TLS_password_reset = "Сбросить пароль";
</code-php>

==gui/templates/tcView.tpl==
<code-php>
$TLS_no_records_found = "Ничего не найдено.";
</code-php>

==gui/templates/execSetResults.tpl==
<code-php>
$TLS_alt_attachment_mgmt = "вложения";
$TLS_alt_notes = "заметки";
$TLS_attachment_mgmt = "вложения";
$TLS_btn_history_off = "Показывать только последний прогон";
$TLS_btn_history_on = "Показывать полную историю прогонов";
$TLS_btn_save_all_tests_results = "Сохранить все результаты прогонов";
$TLS_btn_save_tc_exec_results = "Сохранить результат прогона";
$TLS_bug_mgmt = "Управление багами";
$TLS_build_is_closed = "Сборка закрыта";
$TLS_builds_notes = "Описание сборки";
$TLS_bulk_tc_status_management = "Массовое управление состоянием Тестов";
$TLS_date_time_run = "Дата";
$TLS_details = "Подробности";
$TLS_exec_notes = "Заметки";
$TLS_exec_status = "Состояние";
$TLS_execution_history = "История прогонов";
$TLS_img_title_bug_mgmt = "Управление багами";
$TLS_img_title_delete_execution= "Удалить прогон";
$TLS_just_last_execution_for_this_build = "Последний прогон для этой сборки";
$TLS_no_data_available = "Данные отсутствуют";
$TLS_set_all_tc_to = "Установить всем состояние ";
$TLS_show_hide = "Показать / скрыть";
$TLS_tc_not_tested_yet = "Еще не протестировано:";
$TLS_test_cases_cannot_be_executed = "Тесты не могут быть выполнены";
$TLS_test_exec_by = "Протестировано: ";
$TLS_test_exec_expected_r = "Ожидаемые результаты";
$TLS_test_exec_last_run_date = "Самые последние запуски:";
$TLS_test_exec_notes = "Заметки / Описание";
$TLS_test_exec_on_build = " в Сборке";
$TLS_test_exec_result = "Результат";
$TLS_test_exec_steps = "Шаги";
$TLS_test_exec_summary = "Резюме";
$TLS_test_plan_notes = "Заметки по плану тестирования";
$TLS_test_status_not_run = "Не запущен";
$TLS_th_test_case_id = "ID ";
$TLS_th_testsuite = "Группа тестов";
$TLS_title_t_r_on_build = "Результы тестов по Сборке";
$TLS_title_t_r_owner = " Ответственный:";
$TLS_title_test_case = "Тест";
$TLS_version = "Версия";
</code-php>

==gui/templates/inc_testsuite_viewer_ro.tpl==
<code-php>
$TLS_keywords = "Ключевые слова";
$TLS_test_suite = "Группа тестов";
</code-php>

==gui/templates/navBar.tpl==
<code-php>
$TLS_home = "Домой";
$TLS_link_logout = "Выход";
$TLS_product = "Проект";
$TLS_product_role = "Роль проекта";
$TLS_title_edit_personal_data = "Мой профиль";
$TLS_title_execute = "Выполнить";
$TLS_title_results = "Отчеты";
$TLS_title_specification = "Спецификация";
</code-php>

==gui/templates/inc_testsuite_viewer_rw.tpl==

==gui/templates/planAddTC_m1.tpl==
<code-php>
$TLS_add_tc = "Добавить";
$TLS_add_remove_selected_tc_hint = "Операция будет выполнена над ВСЕМИ группами тестов";
$TLS_btn_add_remove_selected_tc = "Добавить / Удалить выбранное";
$TLS_btn_add_selected_tc = "Добавить выбранное";
$TLS_btn_check = "Отметить";
$TLS_btn_uncheck = "Снять отметки";
$TLS_check_uncheck_tc = "Все тесты в этой группе тестов.";
$TLS_check_uncheck_all_checkboxes="отметить все/снять все отметки";
$TLS_has_been_executed = "были выполнены";
$TLS_inactive_testcase = "неактивны";
$TLS_no_testcase_available = "Тестов нет";
$TLS_note_keyword_filter = "Тесты фильтруются по ключевому слову";
$TLS_remove_tc = "Удалить";
$TLS_th_test_case = "Тест";
$TLS_title_add_remove_test_to_plan = "Добавить/Удалить Тест(ы) в/из плана тестирования";
$TLS_title_add_test_to_plan = "Добавить Тесты в план тестирования";
$TLS_warning_add_remove_selected_tc = "Вы уверены удалить выбранные Тесты из этого плана тестирования?";
</code-php>

==gui/templates/planAddTCNavigator.tpl==
<code-php>
$TLS_title_navigator = "Навигатор";
</code-php>

==gui/templates/planPriority.tpl==
<code-php>
$TLS_btn_upd_prio = "Сохранить";
$TLS_title_priority = "Определить приоритеты для плана тестирования";
$TLS_tr_th_importance = "Важность";
$TLS_tr_th_prio_cba = "Приоритет (C/B/A)";
$TLS_tr_th_risk = "Риск/Важность";
</code-php>

==gui/templates/planEdit.tpl==
<code-php>
$TLS_btn_testplan_create = "Создать";
$TLS_cancel = "Отменить";
$TLS_opt_no = "Нет";
$TLS_testplan_question_create_tp_from = "Создать из существующего плана тестирования?";
$TLS_testplan_th_active = "Активный";
$TLS_testplan_th_name = "Имя";
$TLS_testplan_th_notes = "Описание";
$TLS_testplan_title_create = "Создать новый план тестирования";
$TLS_testplan_title_edit = "Править план тестирования";
$TLS_testplan_title_for_project = "для проекта: ";
$TLS_testplan_title_tp_management = "Управление планами тестирования";
$TLS_testplan_txt_notes = <<<END
План тестирования должен содержать ясно определенные задачи, включая временные границы.
Он может содержать тест-активность для выпускаемой версии продукта (включая патчи)
или просто единственный запрос от пользователя.<br/>
В описании можно ссылаться на план и другую документацию по проекту.
Разумно перечислить тестируемые возможности, риски и т.п.<br/>
Можно создать новый план тестирования из существующего ("клонировать").
Будут скопированы следующие элементы: Сборки, Тесты, Приоритеты,
Вехи и роли пользователей.<br/>
План тестирования можно деактивировать/заморозить: т.е. запретить любое изменение
атрибутов или вложенных элементов плана тестирования.
Такие планы тестирования будут видны только на странице отчетов и на этой странице.
END;

$TLS_warning_empty_tp_name = "Пожалуйста, введите имя плана тестирования.";
</code-php>

==gui/templates/planNew.tpl==
<code-php>
$TLS_testplan_btn_edit = "Сохранить";
$TLS_testplan_btn_new = "Создать";
$TLS_testplan_menu_create = "Создать";
$TLS_testplan_menu_edit = "Править";
$TLS_testplan_menu_list = "Список";
</code-php>

==gui/templates/planMilestones.tpl==
<code-php>
$TLS_alt_delete_milestone = "Удалить веху?";
$TLS_btn_edit_milestone = "Править";
$TLS_btn_new_milestone = "Создать";
$TLS_info_milestones_date = "Веха не может иметь дату раньше чем 'сегодня'";
$TLS_no_milestones = "Для этого плана тестирования вехи не определены.";
$TLS_popup_delete_milestones = "Вы уверены удалить веху %NAME% ?";
$TLS_warning_empty_milestone_name="Укажите имя вехи!";

$TLS_th_date_format = "Целевая Дата";
$TLS_th_perc_a_prio = "% A-приоритет";
$TLS_th_perc_b_prio = "% B-приоритет";
$TLS_th_perc_c_prio = "% C-приоритет";
$TLS_title_existing_milestones = "Существующие вехи";
$TLS_title_milestones = "Вехи для плана тестирования";
$TLS_title_new_milestone = "Новая Веха";
</code-php>

==gui/templates/projectedit.tpl==
<code-php>
$TLS_btn_activate = "Активировать";
$TLS_btn_del = "Удалить";
$TLS_btn_edit_del = "Править / Удалить";
$TLS_btn_inactivate = "Деактивировать";
$TLS_caption_edit_product = "Править проект";
$TLS_caption_new_product = "Создать проект";
$TLS_color = "Цвет";
$TLS_enable_requirements = "Включить функциональность Требований";
$TLS_info_failed_loc_prod = "Не удалось локализовать проект.";
$TLS_notes = "Заметки";
// Warning!!! - if JS string you must use \\n to get \n
$TLS_popup_product_delete = <<<END
Внимание! Вы собираетесь необратимо удалить все данные связанные проектом:
результаты тестов, планы тестирования, тесты и т.п. \\n
Вместо удаления вы можете деактивировать проект. \\n
Если вы всё-таки настроены удалить проект, рекомендуем вам сначала
сделать бэкап базы данных. \\n
Итак, вы по прежнему уверены удалить проект?
END;
$TLS_warning_empty_tproject_name = "Обязательно задайте имя проекта!";
</code-php>

==gui/templates/reqAssign.tpl==
<code-php>
$TLS_please_select_a_req = "Пожалуйста, выберите требование";
$TLS_req_msg_norequirement66 = "Требования нет";
$TLS_req_title_assign = "Привяжите требования к тесту";
$TLS_req_title_assigned = "Привязанные требования";
$TLS_req_title_unassigned = "Доступные требования";
$TLS_warning_req_tc_assignment_impossible = <<<END
<p>
Вы <b>не можете</b> делать привязку по одной из следующих причин:
<ul>
<li>Не определено ни одной спецификации требования;
<li>Спецификации требований пусты.
</ul>
END;
</code-php>

==gui/templates/tcEdit.tpl==
<code-php>
$TLS_title_edit_tc = "Править Тест";
$TLS_warning_editing_executed_tc = "Внимание: Этот версия теста уже выполнялась";
</code-php>

==gui/templates/planOwner.tpl==
<code-php>
$TLS_assign_ownership = "Назначить ответственного";
$TLS_def_prio_rules = "Определить правила приоритетов";
$TLS_opt_label_none = "нет";
$TLS_th_imp = "Важность";
$TLS_th_owner = "Тестировщик";
$TLS_th_risk = "Риск";
$TLS_th_test_suite = "Группа тестов";
$TLS_title_plan_ownership = "Владелец плана тестирования";
</code-php>

==gui/templates/tcView_viewer.tpl==
<code-php>
$TLS_activate_this_tcversion = "Активировать эту версию";
$TLS_Requirements = "Требования";
$TLS_btn_del_this_version = "Удалить эту версию";
$TLS_btn_edit = "Править";
$TLS_btn_mv_cp = "Переместить/Копировать";
$TLS_btn_new_version = "Создать новую версию";
$TLS_can_not_edit_tc = "Вы не можете редактировать эту версию, т.к. она уже выполнялась";
$TLS_deactivate_this_tcversion = "Деактивировать эту версию";
$TLS_tcversion_is_inactive_msg = "Эта версия <b>неактивна</b>, и не будет доступна для включения в план тестирования";
</code-php>

==gui/templates/planRemoveTC_m1.tpl==
<code-php>
$TLS_btn_remove_selected_tc = "Удалить выбранные тесты tcs";
$TLS_remove_ok = "Удаление прошло успешно ok";
$TLS_title_remove_test_from_plan = "Удалить тест из плана тестирования";
</code-php>

==gui/templates/planTesters.tpl==
<code-php>
$TLS_btn_save = "Сохранить";
</code-php>

==gui/templates/keywordsAssign.tpl==
<code-php>
$TLS_keyword_assignment_empty_tsuite = "В этой группе тестов нет тестов => ключевое слово привязать нельзя";
$TLS_menu_assign_kw_to_tc = "Привязать к тестам";
$TLS_menu_manage_keywords = "Управление ключевыми словами";
$TLS_title_keywords = "Ключевые слова";
</code-php>

==gui/templates/planTestersNavigator.tpl==
<code-php>
$TLS_label_list_of = "Список ";
$TLS_opt_test_plans = "планов тестирования";
$TLS_opt_users = "пользователей";
</code-php>

==gui/templates/planUpdateTC.tpl==
<code-php>
$TLS_btn_upd_ck_tc = "Изменить выбранные тест(ы)";
$TLS_info_all_tc_uptodate = "Все тесты актуальны.";
$TLS_th_category = "Группа тестов";
$TLS_th_component = "Группа тестов";
$TLS_th_id_tc = "[ID] Теста";
$TLS_th_reason = "Причина правки";
$TLS_th_spec_version = "Специальная версия";
$TLS_th_status = "Состояние";
$TLS_th_suite_version = "Версия группы тестов";
$TLS_th_update = "Изменить";
$TLS_title_upd_mod_tc = "Изменить исправленные тесты в ";
</code-php>

==gui/templates/keywordsView.tpl==
<code-php>
$TLS_alt_delete_keyword = "Удалить ключевое слово?";
$TLS_btn_create_keyword = "Создать ключевое слово";
$TLS_btn_edit_keyword = "Править";
$TLS_btn_import_keywords = "Импорт";
$TLS_th_keyword = "Ключевое слово";
$TLS_warning_delete_keyword = "Вы уверены удалить ключевое слово?";
$TLS_warning_enter_at_least1 = "Пожалуйста, введите хотя бы ";
$TLS_warning_enter_at_least2 = " символов.";
$TLS_warning_enter_less1 = "Пожалуйста, используйте не больше чем";
$TLS_warning_enter_less2 = " символов.";
</code-php>

==gui/templates/reqexport.tpl==
<code-php>
$TLS_title_req_export_to = "Экспорт требований";
</code-php>

==gui/templates/resultsAllBuilds.tpl==
<code-php>
$TLS_test_status_blocked = "Блокирован";
$TLS_test_status_failed = "Сбой";
$TLS_test_status_passed = "Пройден";
$TLS_th_build = "Сборка";
$TLS_th_tc_total = "Всего тестов";
</code-php>

==gui/templates/resultsBugs.tpl==
<code-php>
$TLS_date = "Дата:";
$TLS_printed_by = "Напечатано:";
$TLS_title_test_case_bugs = "Баги по тесту";
$TLS_title_test_case_timestamp = "Временная метка теста";
$TLS_title_test_case_title = "Заголовок теста";
$TLS_title_test_suite_name = "Имя группы тестов";
</code-php>

==gui/templates/resultsBuild.tpl==
<code-php>
$TLS_title_met_of_build = "Метрики сборки";
</code-php>

==gui/templates/resultsByStatus.tpl==
<code-php>
$TLS_info_test_results = <<<END
<p>
Показываются результаты только последнего теста.
<p>
В частности, тесты скрыты, если результаты тестов для следующей сборки
имеют статус отличный от "в процессе".
END;

$TLS_th_bugs = "Баги";
$TLS_th_date = "Дата";
$TLS_th_run_by = "Запустил:";
</code-php>

==gui/templates/resultsGeneral.tpl==
<code-php>
$TLS_title_gen_test_rep = "Общие метрики плана тестирования";
</code-php>

==gui/templates/resultsMoreBuilds_query_form.tpl==
<code-php>
$TLS_excel_format = "MS Excel";
$TLS_html_format = "HTML";
$TLS_last_status_any = "Любой";
$TLS_last_status_blocked = "Блокирован";
$TLS_last_status_failed = "Сбой";
$TLS_last_status_not_run = "Не стартовал";
$TLS_last_status_passed = "Пройден";
$TLS_select_builds_header = "Выберите сборку(и)";
$TLS_select_components_header = "Выберите группу тестов";
$TLS_select_keyword_header = "Выберите ключевое слово";
$TLS_select_last_result_header = "Выберите последний результат";
$TLS_select_owner_header = "Выберите владельца";
$TLS_select_report_format_header = "Выберите формат отчета";
$TLS_submit_query = "Выполнить запрос";
$TLS_test_plan_header = "План тестирования: ";
$TLS_query_metrics_report = "Запросить отчет по метрикам";
$TLS_enter_start_time = "Введите начальное время";
$TLS_enter_end_time = "Введите конечное время";
$TLS_year = "год";
$TLS_month = "месяц";
$TLS_day = "день";
$TLS_hour = "час";
$TLS_search_in_notes = "поиск строки в заметках";
$TLS_executor = "исполнитель";
</code-php>

==gui/templates/resultsMoreBuilds_report.tpl==
<code-php>
$TLS_caption_show_collapse = "Показать/Свернуть";
$TLS_caption_user_selected_query_parameters = "Параметры запроса";
$TLS_not_yet_executed = "Еще не выполнялся";
$TLS_show_hide_all = "Показать/Скрыть все";
$TLS_th_builds = "Сборка(и)";
$TLS_th_execution_ts = "Время";
$TLS_th_last_result = "Последний результат";
$TLS_th_report_format = "Тип отчета";
$TLS_th_test_plan = "План тестирования";
$TLS_th_test_suites = "Группа(ы) тестов";
$TLS_th_tester_id = "Тестировщик";
$TLS_th_total_block = "# блокированных ";
$TLS_th_total_cases = "# тестов";
$TLS_th_total_fail = "# сбоев";
$TLS_th_total_not_run = "# не стартовавших";
$TLS_th_total_pass = "# выполненных";
$TLS_th_start_time = "Время начала";
$TLS_th_end_time = "Время окончания";
$TLS_th_executor = "Исполнитель";
$TLS_th_search_notes_string = "в заметках искать строку";
$TLS_true = "да";
$TLS_false = "нет";
$TLS_display_suite_summaries = "Показать итоги по группе тестов";
$TLS_display_query_params = "Показать параметры запроса";
$TLS_display_totals = "Показать суммарную информацию";
</code-php>

==gui/templates/resultsReqs.tpl==
<code-php>
$TLS_req_title_blocked = "Заблокировано требований";
$TLS_req_title_failed = "Нарушено требований";
$TLS_req_title_notrun = "Непроверенных требований";
$TLS_req_title_passed = "Выполнено требований";
$TLS_title_result_req_testplan = "Результаты тестов основанных на спецификации требований";
$TLS_title_test_plan = "План тестирования";
</code-php>

==gui/templates/resultsSend.tpl==
<code-php>
$TLS_btn_send_report = "Послать отчет";
$TLS_check_send_to_me = "Послать отчет самому себе";
$TLS_mail_body = "Тело письма:";
$TLS_mail_report = "Отчет:";
$TLS_mail_subject = "Тема письма:";
$TLS_mail_to = "Кому:";
$TLS_status_for_build = "Состояние сборки";
$TLS_tp_status = "Общее состояние плана тестирования";
$TLS_tp_status_for_build = "Состояние плана тестирования для сборки";
</code-php>

==gui/templates/resultsTC.tpl==
<code-php>
$TLS_generated_by_TestLink_on="Сформировано системой TestLink, ";
</code-php>

==gui/templates/tcEdit_m2.tpl==

==gui/templates/tcPrintNavigator.tpl==
<code-php>
$TLS_caption_print_opt = "Настройки печати";
$TLS_tr_td_show_as = "Показать как";
</code-php>

==gui/templates/tcReorder.tpl==
<code-php>
$TLS_no_tc_to_reorder = "Нет тестов для переупорядочивания.";
$TLS_title_change_tc_order = "Изменить порядок тестов в этой группе тестов.";
</code-php>

==gui/templates/tcTree.tpl==
<code-php>
$TLS_button_refresh = "Обновить";
$TLS_button_update_tree = "Обновить дерево";
$TLS_do_auto_update = "Обновлять дерево после каждой операции";
$TLS_no_tc_spec_av = "Нет тест-спецификаций.";
</code-php>

==gui/templates/tc_exec_assignment.tpl==
<code-php>
$TLS_btn_do = "Пуск";
$TLS_btn_update_selected_tc = "Изменить выбранные тесты";
$TLS_title_tc_exec_assignment = "Назначить прогоны тестов для плана тестирования ";
$TLS_user = "Пользователь";
$TLS_user_bulk_assignment = "Массовое назначение ответственных пользователей";
</code-php>

==gui/templates/testSetNavigator.tpl==

==gui/templates/userInfo.tpl==
<code-php>
$TLS_btn_change_passwd = "Сменить пароль";
$TLS_btn_upd_user_data = "Изменить";
$TLS_th_new_passwd = "Новый пароль";
$TLS_th_new_passwd_again = "Повторите новый пароль";
$TLS_th_old_passwd = "Старый пароль";
$TLS_title_account_settings = "Настройки профиля";
$TLS_title_change_your_passwd = "Сменить ваш пароль";
$TLS_warning_different_pwd = "Пожалуйста, повторите еще раз ваш новый пароль. Введенные пароли не совпадают.";
$TLS_warning_empty_pwd = "Пароль должен быть не пуст!";
$TLS_your_password_is_external = "Ваш пароль ведётся во внешней системе";
</code-php>

==gui/templates/usersassign.tpl==
<code-php>
$TLS_TestProject = "проект";
$TLS_User = "Пользователь";
$TLS_btn_change = "Изменить";
$TLS_caption_assign_testplan_user_roles = "Назначить роли плана тестирования пользователям";
$TLS_caption_assign_testproject_user_roles = "Назначить роли проекта пользователям";
$TLS_menu_assign_testproject_roles = "Назначить роли проекта";
$TLS_th_roles = "Роли";
$TLS_title_assign_roles = "Назначить роли";
</code-php>

==gui/templates/usersedit.tpl==
<code-php>
$TLS_button_reset_password = "Сбросить пароль";
$TLS_caption_user_details = "Свойства пользователя";
$TLS_th_password = "Пароль";
$TLS_warning_empty_first_name = "Пожалуста, введите имя";
$TLS_warning_empty_last_name = "Пожалуйста, введите фамилию";
$TLS_warning_empty_login = "Пожалуйста, введите логин";
</code-php>

==gui/templates/attachmentupload.tpl==
<code-php>
$TLS_attachment_upload_ok="Файл загружен.";
$TLS_enter_attachment_title = "Введите заголовок для этого вложения.";
$TLS_import_was_ok = "Импорт прошел успешно.";
$TLS_max_size_cvs_file = "Максимальный размер файла:";
$TLS_title_upload_attachment = "Загрузить вложение";
</code-php>

==gui/templates/rolesview.tpl==
<code-php>
$TLS_N_A = "N/A";
$TLS_alt_delete_role = "Удалить роль";
$TLS_alt_edit_role = "Править роль";
$TLS_btn_confirm_delete = "Удалить";
$TLS_no_roles = "Нет ролей";
$TLS_title_roles = "Доступные роли";
$TLS_warning_users_will_be_reset = "'Задетым пользователям' будет назначена гостевая роль!";
</code-php>

==gui/templates/tcexport.tpl==
<code-php>
$TLS_export_with_keywords = "Экспортировать с ключевыми словами";
</code-php>

==gui/templates/buildView.tpl==
<code-php>
$TLS_alt_active_build = "Активная сборка";
$TLS_alt_edit_build = "Редактировать эту сборку";
$TLS_alt_open_build = "Открыть сборку";
$TLS_btn_build_create = "Создать";
$TLS_no_builds = "В этот плане тестирования сборок не определено.";
$TLS_th_description = "Описание";
$TLS_th_open = "Открыть";
$TLS_title_build_list = "Список существующих сборок";
$TLS_warning_delete_build = <<<END
<p>Вы действительно хотите уничтожить эту сборку? <p>
Все связанные данные (в частности, результаты тестов) будут также удалены!";
END;
</code-php>

==gui/templates/planView.tpl==
<code-php>
$TLS_testplan_alt_delete_tp = "Удалить этот план тестирования?";
$TLS_testplan_alt_edit_tp = "Править план тестирования";
$TLS_testplan_msg_delete_confirm = <<<END
Вы уверены, что хотите удалить план тестирования? <p>
План тестирования можно деактивировать не удаляя.
END;

$TLS_testplan_th_delete = "Удалить";
$TLS_testplan_title_list = "Список планов тестирования";
$TLS_testplan_txt_empty_list = <<<END
Ни одного плана тестирования не определено! <p>
Чтобы воспользоваться функциональностью прогонов тестов, нужно
создать хотя бы один.
END;
$TLS_alt_active_testplan = "Активный план тестирования";
</code-php>

==gui/templates/mainPage_left.tpl==
<code-php>
$TLS_href_assign_user_roles = "Назначить пользовательские роли";
$TLS_href_browse_tc = "Просмотр тестов";
$TLS_href_cfields_management = "Управление пользовательскими полями";
$TLS_href_cfields_tproject_assign = "Привязка пользовательских полей";
$TLS_href_create_product = "Создать новый проект";
$TLS_href_edit_product = "Править/Удалить проект";
$TLS_href_edit_tc = "Редактировать тесты";
$TLS_href_keywords_assign = "Привязать ключевые слова";
$TLS_href_keywords_manage = "Управление ключевыми словами";
$TLS_href_keywords_view = "Просмотр ключевых слов";
$TLS_href_print_tc = "Печать тестов";
$TLS_href_req_assign = "Привязать требования";
$TLS_href_req_spec = "Спецификация требований";
$TLS_href_roles_management = "Управление ролями";
$TLS_href_search_tc = "Искать тест(ы)";
$TLS_href_user_management = "Управление пользователями";
$TLS_title_requirements = "Требования";
$TLS_title_test_spec = "Спецификации тестов";
$TLS_title_product_mgmt = "Управление проектами";
</code-php>

==gui/templates/mainPage_right.tpl==
<code-php>
$TLS_filter_tp_by_product = "Фильтровать план тестирования по проектам";
$TLS_href_add_test_case = "Добавить тест(ы)";
$TLS_href_build_new = "Управление сборками";
$TLS_href_execute_test = "Выполнить тесты";
$TLS_href_plan_assign_priority = "Установить приоритеты";
$TLS_href_plan_define_priority = "Определить правила приоритетов";
$TLS_href_plan_management = "Управление планами тестирования";
$TLS_href_plan_mstones = "Управление вехами";
$TLS_href_print_tc_suite = "Печать плана тестирования";
$TLS_href_remove_test_case = "Удалить Тест(ы)";
$TLS_href_rep_and_metrics = "Отчеты и метрики";
$TLS_href_tc_exec_assignment = "Поручить прогон тестов";
$TLS_href_upd_mod_tc = "Сохранить измененные тесты";
$TLS_msg_no_rights_for_tp = "- недоступен (У вас нет доступа ни для одного плана тестирования)";
$TLS_testplan_role = "Роль плана тестирования";
$TLS_title_test_case_suite = "Содержание плана тестирования";
$TLS_title_test_execution = "Выполнение плана тестирования";
$TLS_title_test_plan_mgmt = "Управление планами тестирования";
$TLS_href_newest_tcversions = "Показать тесты с самыми свежими версиями";
</code-php>

==lib/execute/bug_add.php==
<code-php>
$TLS_bug_added = "Баг добавлен";
$TLS_error_bug_does_not_exist_on_bts="Бага с таким ID не зарегистрировано в BTS!";
$TLS_error_wrong_BugID_format = "Неверный формат BugID!";
</code-php>

==lib/execute/bug_delete.php==
<code-php>
$TLS_bugdeleting_was_ok = "Баг успешно удален.";
</code-php>

==lib/functions/doAuthorize.php==
<code-php>
$TLS_error_ldap_auth_failed = "LDAP-аутентификация не удалась";
$TLS_error_ldap_bind_failed = "Не удалось выполнить LDAP-binding";
$TLS_error_ldap_server_connect_failed = "Не удалось соединится с LDAP-сервером";
$TLS_error_ldap_update_failed = "Обновление LDAP не удалось";
$TLS_error_ldap_user_not_found = "LDAP-пользователь не найден";
</code-php>

==lib/functions/product.inc.php==
<code-php>
$TLS_info_product_delete_fails = "При удалении этого проекта произошла ошибка";
</code-php>

==lib/functions/results.inc.php==
<code-php>
$TLS_trep_failing = "Провалены";
$TLS_trep_passing = "Прошли";
$TLS_trep_status_for_build = "Состояние для сборки";
$TLS_trep_status_for_ts = "Состояние для группы тестов";
$TLS_unassigned = "Не назначены";
</code-php>

==lib/functions/resultsMoreBuilds.inc.php==
<code-php>
$TLS_bugs = "Связанные Баги";
$TLS_builds_selected = "Сборка(и)";
$TLS_case_not_run_warning = "Тест не запущен";
$TLS_category_header = "Группа тестов =";
$TLS_daterun = "Дата запуска";
$TLS_last_status = "Последнее состояние";
$TLS_number_blocked = "# блокированных";
$TLS_number_cases = "# тестов";
$TLS_number_executions = "# тест-пусков";
$TLS_number_failed = "# тест-сбоев";
$TLS_number_not_run = "# не запущено";
$TLS_number_passed = "# пройденных";
$TLS_owner = "Тестировщик";
$TLS_owner_header = "Tester =";
$TLS_runby = "Запущен тестировщиком ";
$TLS_test_plan_name = "План тестирования";
</code-php>

==lib/functions/roles.inc.php==
<code-php>
$TLS_desc_cfield_management = "Управление пользовательскими полями";
$TLS_desc_cfield_view = "Просмотр пользовательских полей (read-only)";
$TLS_desc_mgt_modify_key = "Управление ключевыми словами";
$TLS_desc_mgt_modify_product= "Управление проектами";
$TLS_desc_mgt_modify_req = "Управление требованиями";
$TLS_desc_mgt_modify_tc = "Создание/правка тестов";
$TLS_desc_mgt_modify_users = "Управление пользователями";
$TLS_desc_mgt_view_key = "Просмотр ключевых слов (read-only)";
$TLS_desc_mgt_view_req = "Просмотр требований (read-only)";
$TLS_desc_mgt_view_tc = "Просмотр Тестов (read-only)";
$TLS_desc_role_management = "Управление ролями";
$TLS_desc_testplan_create_build = "Создание/редактирование сборки";
$TLS_desc_testplan_execute = "Выполнение плана тестирования";
$TLS_desc_testplan_metrics = "Метрики плана тестирования";
$TLS_desc_testplan_planning = "Составление плана тестирования";
$TLS_desc_user_role_assignment = "Назначение ролей";
$TLS_error_duplicate_rolename = "Роль с таким именем уже есть!";
$TLS_error_role_no_rights = "Вы не можете создать роль без каких-либо прав!";
$TLS_error_role_no_rolename = "Вам нужно ввести имя для этой роли.";
$TLS_mgt_testplan_create = "Создать/править план тестирования";
</code-php>

==lib/functions/testproject.class.php==
<code-php>
$TLS_error_creating_req_spec = "Ошибка при создании спецификации требования";
$TLS_info_product_name_empty = "Нельзя давать пустое имя.";
$TLS_keyword_already_exists = "Такое ключевое слово уже есть";
$TLS_string_contains_bad_chars = "Введенная строка содержит недопустимые символы.";
$TLS_warning_duplicate_req_title= "Требование с таким заголовком уже есть.";
</code-php>

==lib/functions/requirements.inc.php==
<code-php>
$TLS_conflict = "Конфликт";
$TLS_error_deleting_req = "Ошибка при удалении требования(й).";
$TLS_error_inserting_req = "Ошибка при вставке требования(й).";
$TLS_error_updating_req = "Ошибка при правке требования(й).";
$TLS_error_updating_reqspec = "Ошибка при правке спецификаций требований.";
$TLS_file_is_not_xml = "Файл не распознан как корректный XML, и не может быть использован.";
$TLS_ok = "OK";
$TLS_req_import_format_description1 = " - тип CSV требует три поля на каждую запись: 'req_doc_id','title','description'";
$TLS_req_import_format_description2 = " - CSV, экспортированный из DOORS требует запись-заголовок.";
$TLS_req_import_result_overwritten = "перезаписано!";
$TLS_req_import_result_skipped = "пропущено";
$TLS_req_state_not_testable = "не тестируемо";
$TLS_req_state_valid = "актуально";
$TLS_the_format_req_xml_import = "Неверный XML-формат для импорта требований";
$TLS_warning_duplicate_reqdoc_id = "Не уникальный (дублирующий) id документа";
</code-php>

==lib/functions/testsuite.class.php==
<code-php>
$TLS_component_name_already_exists = "Группа тестов с таким именем уже зарегистрирована";
$TLS_testsuite = "Группа тестов";
</code-php>

==lib/functions/exec.inc.php==
<code-php>
$TLS_test_results_submitted = "Результаты тестов отправлены.";
</code-php>

==lib/functions/print.inc.php==
<code-php>
$TLS_author = "Автор";
$TLS_printed_by_TestLink_on = "Распечатано TestLink'ом ";
$TLS_title_toc = "Содержание";
$TLS_passfail = "Пройден / Провален";
$TLS_testnotes = "Заметки к тесту";
</code-php>

==lib/functions/testcase.class.php==
<code-php>
$TLS_testcase_name_already_exists = "Тест с таким именем уже есть!";
$TLS_the_format_tc_xml_import = "";
</code-php>

==lib/functions/info.inc.php==
<code-php>
$TLS_email_sent_message = "Ваше письмо отослано.";
</code-php>

==lib/functions/users.inc.php==
<code-php>
$TLS_Unknown = "Неизвестно";
$TLS_duplicate_login = "Пользователь с таким логином уже есть!";
$TLS_login_must_not_be_empty = "Логин не должен быть пустым!";
$TLS_wrong_old_password = "Старый пароль неверен!";
</code-php>

==lib/functions/email_api.php==
<code-php>
$TLS_stmp_host_unconfigured = "Некорректно указан SMTP host!";
</code-php>

==lib/functions/common.php==

==lib/functions/configCheck.php==
<code-php>
$TLS_attachments_dir = "каталог для вложений:";
$TLS_bts_connection_problems = <<<END
Не удалось соединиться с вашей Bug Tracking System.<p>
Пожалуйста, проверьте настройки.<p>
Будьте внимательны, эта проблема
снижает производительность TestLink'а.
END;

$TLS_but_directory_is_not_writable = "Каталог закрыт для записи!";
$TLS_directory_is_writable = "Каталог открыт для записи.";
$TLS_does_not_exist = "не существует";
$TLS_exists = "существует";
$TLS_ldap_extension_not_loaded=<<<END
Метод аутентификации указан как LDAP </br>
однако PHP/LDAP extension не загружено =>
Вам не удастся войти в систему.
Пожалуйста, свяжитесь с администратором TestLink'а.
END;
$TLS_sec_note_admin_default_pwd = "Вам необходимо сменить пароль по умолчанию у пользователя 'admin'!";
$TLS_sec_note_remove_install_dir = "Инсталляционный каталог должен быть удален!";
</code-php>

==lib/general/frmWorkArea.php==
<code-php>
$TLS_create_a_build = "Создать новую сборку";
$TLS_no_build_warning_part1 = "Ни одной сборки для этого тест плана не создано.";
$TLS_no_build_warning_part2 = "Создайте их или попросите об этом свое руководство.";
</code-php>

==lib/general/myTPInfo.php==
<code-php>
$TLS_no_testplans_available = "К сожалению, ни одного плана тестирования не доступно";
</code-php>

==lib/general/tlsmarty.inc.php==

==lib/keywords/keywords.inc.php==
<code-php>
$TLS_empty_keyword_no = "Ключевое слово должно быть непустым!";
$TLS_keywords_char_not_allowed = "Запятые и кавычки недопустимы в ключевых словах!";
$TLS_tc_kw_update_fails1 = "Тест";
$TLS_tc_kw_update_fails2 = " дал сбой ";
$TLS_the_format_keyword_csv_import = "keyword;notes";
$TLS_the_format_keyword_xml_import = "<keywords><keyword name=\"name\">Notes</keyword></keywords>";
</code-php>

==lib/keywords/keywordsView.php==
<code-php>
$TLS_kw_delete_fails = "Не удалось удаление ключевого слова!";
$TLS_kw_update_fails = "Не удалась правка ключевого слова!";
</code-php>

==lib/keywords/keywordsAssign.php==
<code-php>
$TLS_assigned_kword = "Связанные ключевые слова";
$TLS_available_kword = "Доступные ключевые слова";
</code-php>

==lib/plan/buildNew.php==
<code-php>
$TLS_cannot_add_build = "Невозможно добавить сборку!";
$TLS_cannot_delete_build = "Невозможно удалить сборку!";
$TLS_cannot_update_build = "Ошибка при правке сборки!";
$TLS_warning_duplicate_build = "Сборка с таким идентификатором уже есть.";
</code-php>

==lib/plan/plan.inc.php==
<code-php>
$TLS_warning_empty_milestone_name = "Обязательно введите имя для вехи!";
$TLS_warning_enter_valid_date = "Введенная дата некорректна!";
$TLS_warning_invalid_percentage_value = "Значения-проценты должны быть от 0 to 100 (%)";
$TLS_warning_milestone_date = "Веха не может иметь дату раньше чем 'сегодня'!";
$TLS_warning_percentage_value_higher_than_100 = "Сумма всех значений-процентов не должна быть больше 100!";
</code-php>

==lib/plan/planMilestones.php==
<code-php>
$TLS_milestone_delete_fails = "Не удалось удалить веху!";
$TLS_warning_milestone_add_failed = "Не удалось добавить веху!";
$TLS_warning_milestone_update_failed = "Не удалось править веху!";
</code-php>

==lib/plan/planOwner.php==
<code-php>
$TLS_opt_imp_high = "Высокая";
$TLS_opt_imp_low = "Низкая";
$TLS_opt_imp_medium = "Средняя";
</code-php>

==lib/plan/planTestersEdit.php==
<code-php>
$TLS_title_assign_tp = "Поручить планы тестирования пользователю: ";
$TLS_title_assign_users = "Назначить пользователей на план тестирования: ";
</code-php>

==lib/plan/planTestersNavigator.php==
<code-php>
$TLS_nav_test_plan = "Навигатор - Планы тестирования";
$TLS_nav_users = "Навигатор - Пользователи";
</code-php>

==lib/plan/planUpdateTC.php==
<code-php>
$TLS_category_has_changed = "Группа тестов изменена";
$TLS_component_has_changed = "Группа тестов изменена";
$TLS_deleted = "удалена";
$TLS_different_versions = "Различные версии";
$TLS_plan_update_no_tc_updated = "Ни один тест не изменен";
$TLS_planupdate_tc_deleted1 = "Тест";
$TLS_planupdate_tc_deleted2 = "был удален.";
$TLS_planupdate_tc_updated1 = "Тест";
$TLS_planupdate_tc_updated2 = "был изменен.";
$TLS_tcorder_has_changed = "Порядок тестов был изменен";
$TLS_updated = "изменен";
</code-php>

==lib/plan/testSetNavigator.php==
<code-php>
$TLS_title_test_plan_navigator = "Навигация по планам тестирования";
</code-php>

==lib/plan/testSetRemove.php==
<code-php>
$TLS_tcase_removed_from_tplan="тест удален из плана тестирования";
$TLS_multiple_tcase_removed_from_tplan="Тесты удалены из плана тестирования";
</code-php>

==lib/plan/planEdit.php==
<code-php>
$TLS_testplan_created_ok = "План тестирования был создан";
$TLS_update_tp_failed1 = "Правка плана тестирования '";
$TLS_update_tp_failed2 = "' не удалась";
$TLS_warning_duplicate_tplan_name = "План тестирования с таким именем уже есть. Выберите другое имя!";
</code-php>

==lib/print/selectData.php==
<code-php>
$TLS_opt_show_doc_header = "Показать заголовок документа";
$TLS_opt_show_tc_body = "Показать тело теста";
$TLS_opt_show_tc_summary = "Показать резюме теста";
$TLS_opt_show_toc = "Показать Содержание";
$TLS_opt_show_tc_author = "Показать автора теста";
$TLS_opt_show_passfail = "Показать статус «пройден/провален» и заметки";
$TLS_title_tc_print_navigator = "Навигация - Печать спецификации тестов";
$TLS_title_tp_print_navigator = "Навигация - Печать плана тестирования";
</code-php>

==lib/project/projectedit.php==
<code-php>
$TLS_error_product_name_duplicate = "Уже есть проект с именем %s. <br>Пожалуйста, выберите другое имя";
$TLS_info_no_more_prods = "проектов больше нет.";
$TLS_info_product_activated = "проект активирован.";
$TLS_info_product_inactivated = "проект деактивирован.";
$TLS_info_product_not_deleted_check_log = "Не удалось удалить проект. Проверьте лог TestLink'а.";
$TLS_info_product_was_deleted = "проект успешно удален.";
$TLS_refer_to_log = " Пожалуйста, изучите лог TestLink'а для дополнительной информации.";
$TLS_test_project_activated = "проект %s успешно активирован";
$TLS_test_project_created = "проект %s успешно создан";
$TLS_test_project_deleted = "проект %s успешно удален";
$TLS_test_project_inactivated = "проект %s успешно деактивирован";
$TLS_test_project_updated = "проект %s успешно отредактирован";
$TLS_test_project_update_failed = "Правка проекта %s не удалась!";
</code-php>

==lib/results/charts.php==
<code-php>
$TLS_maani_copyright = "flash technology предоставлена http://www.maani.us";
$TLS_graphical_reports = "Графические отчеты";
$TLS_overall_metrics = "Общие метрики";
$TLS_results_by_keyword = "Результаты по ключевому слову";
$TLS_results_by_tester = "Рузультаты по тестировщику";
$TLS_results_top_level_suites = "Результаты по топ группам тестов";
</code-php>

==lib/req/reqImport.php==
<code-php>
$TLS_file_is_not_ok_for_import_type = "Кажется тип файла не совпадает с выбранным для импорта типом";
$TLS_file_is_not_text = "Это не текстовый файл. Использовать нельзя.";
$TLS_please_choose_req_file = "Пожалуйста, выберите файл для загрузки";
$TLS_req_import_finished = "Импорт завершен!";
</code-php>

==lib/req/reqSpecView.php==
<code-php>
$TLS_cant_create_tc_from_req_nothing_sel = "Пожалуйста, выберите требование!";
$TLS_req_created = "Требование %s успешно создано.";
</code-php>

==lib/req/reqTcAssign.php==
<code-php>
$TLS_req_msg_noselect = "Ничего не выбрано";
$TLS_req_msg_notupdated_coverage = "Покрытие не обновлено для Требований: ";
</code-php>

==lib/results/resultsBugs.php==
<code-php>
$TLS_title_test_report_all_builds = "Отчет: Результаты тестов для всех сборок";
</code-php>

==lib/results/resultsAllBuilds.php==
<code-php>
$TLS_title_metrics_x_build = " - Результаты тестов. Метрики X Сборки";
</code-php>

==lib/results/resultsByStatus.php==
<code-php>
$TLS_list_of_blocked = "Список блокированных тестов";
$TLS_list_of_failed = "Список проваленных тестов";
$TLS_list_of_not_run = "Список незапущенных тестов";
</code-php>

==lib/results/resultsTC.php==

==lib/results/resultsNavigator.php==
<code-php>
$TLS_link_charts="Диаграммы";
$TLS_link_report_blocked_tcs = "Блокированные тесты";
$TLS_link_report_failed = "Проваленные тесты";
$TLS_link_report_general_tp_metrics = "Общие метрики плана тестирования";
$TLS_link_report_metrics_active_build = "Метрики активной сборки";
$TLS_link_report_metrics_more_builds = "Запрос метрик";
$TLS_link_report_not_run="Не запущенные тесты";
$TLS_link_report_overall_build = "Общий статус сборки";
$TLS_link_report_reqs_coverage = "Отчет о выполнении требований";
$TLS_link_report_test = "Отчет по тестам";
$TLS_link_report_total_bugs = "Всего багов по каждому тесту";
</code-php>

==lib/results/resultsSend.php==
<code-php>
$TLS_send_to_empty_email_warning = "Пожалуйста, введите правильный email.";
$TLS_warning_create_build_first = "Сначала Вы должны создать или импортировать сборки.";
</code-php>

==lib/results/displayMgr.php==
<code-php>
$TLS_error_sendreport_no_email_credentials = "Email для этого пользователя не указан, пожалуйста, укажите его в настройках своего профиля";
</code-php>

==lib/testcases/archive.inc.php==

==lib/testcases/listTestCases.php==

==lib/testcases/tcImport.php==
<code-php>
$TLS_please_choose_file_to_import = "Пожалуйста, выберите файл для импорта";
$TLS_title_tc_import_to = "Импорт Тестов";
$TLS_title_tsuite_import_to = "Импорт группы тестов";
$TLS_wrong_xml_tcase_file = "Некорректный XML в файле с тестами";
$TLS_wrong_xml_tsuite_file = "Некорректный XML в файле с группой тестов";
</code-php>

==lib/testcases/tcexport.php==
<code-php>
$TLS_no_testcases_to_export = "Нет тестов для экспорта";
$TLS_no_testsuites_to_export = "Нет группы тестов для экспорта";
$TLS_title_tc_export = "Экспорт теста";
$TLS_title_tc_export_all = "Экспортировать все тесты";
$TLS_title_tsuite_export = "Экспортировать все группы тестов";
$TLS_title_tsuite_export_all = "Экспортировать все группы тестов";
</code-php>

==lib/testcases/containerEdit.php==
<code-php>
$TLS_delete = "Удалить";
$TLS_delete_notice = "Внимание: Все связанные результаты прогонов будут удалены";
$TLS_warning_empty_com_name = "Пожалуйста, задайте имя для группы тестов";
</code-php>

==lib/testcases/tcEdit.php==
<code-php>
$TLS_current = "текущий";
$TLS_delete_linked = "Ссылки на планы тестирования будут удалены.";
$TLS_delete_linked_and_exec = "Ссылки на планы тестирования и результаты выполнения будут удалены.";
$TLS_error_tc_add = "При добавлении теста произошла ошибка";
$TLS_title_del_tc = "Удалить тест ";
</code-php>

==lib/usermanagement/rolesview.php==
<code-php>
$TLS_error_role_deletion = "Не удалось удалить роль!";
</code-php>

==lib/usermanagement/usersassign.php==
<code-php>
$TLS_no_test_projects = "Не заведено ни одного проекта";
$TLS_no_test_plans = "Для этого проекта не заведено ни одного плана тестирования";
$TLS_test_project_user_roles_updated = "Пользовательские роли обновлены";
$TLS_test_plan_user_roles_updated = "Пользовательские роли обновлены";
</code-php>

==lib/usermanagement/usersedit.php==
<code-php>
$TLS_user_created="Пользователь %s был успешно создан";
$TLS_user_deleted="Пользователь %s был успешно удален";
$TLS_user_not_added = "Не удалось добавить пользователя!";
</code-php>

==lib/usermanagement/rolesedit.php==
<code-php>
$TLS_error_role_creation = "Не удалось создать роль!";
$TLS_error_role_update = "Не удалось исправить роль!";
</code-php>

==lib/cfields/cfields_edit.php==
<code-php>
$TLS_cf_name_exists = "Пользовательское поле с таким именем уже существует. Пожалуста, выберите другое имя.";
$TLS_error_creating_cf = "Не удалось создать пользовательское поле!";
$TLS_do_update = "исправлено";
$TLS_do_delete = "удалено";
$TLS_do_add = "добавлено";
</code-php>

==resultsBugs.tpl==
<code-php>
$TLS_Open="Открыто";
$TLS_Resolved="Исправленных";
$TLS_Total="Всего";
$TLS_TCs_with_Bugs="Тестов с багами";
</code-php>