Testlink руководство пользователя

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

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

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

TestLink является кроссплатформенной системой. Для её работы необходимы следующие компоненты:

Web-сервер: Apache, IIS;
СУБД: MySQL, Postgress, MS SQL;

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

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

Узнать более подробную информацию, скачать дистрибутив, а также получить демонстрационный доступ к TestLink можно по ссылке:
http://www.teamst.org/

Система HP Quality Center предназначена для решения круга задач по обеспечению качества программного обеспечения. Как и вышеописанный TestLink система является Web-приложением, но из всех браузеров поддерживается только Internet Explorer. В качестве альтернативы браузеру можно воспользоваться специальным клиентом.
В HP QC предусмотрено также управление требованиями и управление дефектами. Таким образом данная система является полноценным средством управления жизненным циклом ПО. Помимо требований и дефектов в HPQC входят следующие сущности для управления тестами.

Проект - аналогичен проекту в TestLink. Головная сущность, которая включает в себя все остальные элементы: тест-план, тест-кейсы и прочие.
Тест-план - хранилище всех тест-кейсов проекта. Тест-кейсы могут группироваться по тест-сьютам. Таким образом их можно сгруппировать по функционалу или по другим параметрам.
Тестовая лаборатория (Test Lab) - специальный модуль для планирования и выполнения тестов, созданных в тест-плане. Здесь указывается конфигурация и сборка на которой будут выполнятся тесты. Таким образом, после завершения выполнения тестов, можно будет получить отчет по результатам выполнения на конкретной сборке или конфигурации. К сожалению, в HP QC не предусмотрено назначение тестового сценария на конкретного исполнителя. Тем не менее, есть возможность отследить, кто и когда выполнял тот или иной тест.

Система HP QC предоставляет мощные инструменты для получения отчетов. Можно как воспользоваться уже имеющимися отчетами, так и создать собственные с требуемой выборкой информации в нужном срезе.
HP Quality Center является платной системой, лицензируется каждый пользователь, но по различным модулям. Такой подход позволяет не переплачивать за неиспользуемые лицензии. Например, разработчикам нужен доступ только к дефектам, таким образом, нет необходимости приобретать для них лицензию для модулей управления тестами.

Более подробно с HP Quality Center можно ознакомится по ссылке (информация доступна только на английском языке):
http://www.hp.com/go/qualitycenter

Microsoft Test Manager

Система управления тестированием Microsoft Test Manager поставляется в составе Microsoft Visual Studio (начиная с 2010). Это средство для ручного выполнения тестов и для настройки запуска автотестов. Как и Visual Studio, MTM тесно интегрирован с Microsoft TFS. С помощью MTM можно создавать, структурировать и выполнять тесты. Как и вышеописанные системы для управления тестированием, MTM включает в себя такие сущности как тест-план, тест-кейс и конфигурации.
Главной отличительной особенностью MTM является автоматизация сбора информации при заведении дефекта. Если в процессе тестирования тестировщик указал, что кейс не прошел (Failed), то можно или указать номер дефекта если он уже заведен или же завести новый прямо из MTM. При этом в описание дефекта будут скопированы все шаги тест кейса (с указанием «проблемного» шага), к дефекту будут приложены системный «application»-лог и снимок экрана на момент падения теста (если это необходимо). Помимо этого, к дефекту прикладывается вся информация о системе, на которой был воспроизведен дефект. Таким образом у разработчика, которому дефект будет направлен для исправления, будет вся необходимая информация в полном объеме.

Для работы MTM требуется наличие TFS, так как все тест-кейсы хранятся в базе TFS. Главный недостаток MTM — необходимость устанавливать специальный клиент для работы с ним, так как работа через Web интерфейс не поддерживается. Таким образом, данная система управления тестами теряет свои главные преимущества, например, при тестировании Linux-приложений.

Более подробно с возможностями TFS для тестирования можно ознакомится в презентации (доступна только на английском языке):
http://www.slideshare.net/EdBlankenship/full-testing-experience-visual-studio-and-tfs-2010

Устанавливаем Testlink на локальный ПК с Windows

Устанавливаем Testlink на локальный ПК

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

Минимальными требованиями для Testlink являются php 5.4 и mysql сервер. Если вы давно знаете что это и они у вас установлены, то можно пропустить этот шаг. Намного удобнее пользоваться специальными «сборками» — т.е. наборами необходимых инструментов для запуска локального вебсервера, которые включают в себя эти и другие часто используемые инструменты. Примеры таких наборов: Denwer, xampp, wamp и прочие. Раньше, когда мне нужно было запустить какой-то сайт на локальном ПК, я пользовался Denwer’ом, но т.к. в комплекте там идет довольно старая версия Php, а для того же Testlink’а на момент написания статьи уже нужен был минимум php 5.4, мне пришлось отказаться от него в пользу Wamp. По этому в моей статье, в качестве локального вебсервера будет этот набор. (Если у вас уже стоит другой набор, то попробуйте этот шаг пропустить, но если Testlink начнет при установке ругаться, что версия php не подходят, то лучше сэкономьте, то время, что я потратил на попытки нормально обновить пхп в денвере — сотрите его и поставьте wamp).

Скачиваем и устанавливаем свежую версию wampserver с официального сайта .

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

Установка системы тестирования Testlink ничем не отличается от обычной установки какой-нибудь CMS.

Скачиваете архив с Testlink с официального сайта .

На момент написания статьи актуальной версией системы была 1.9.9. по этому после разархивации получаем папку testlink-1.9.9. переименовываем ее в testlink и перемещаем в C:/wamp/www/ (или другой путь www. если у вас wamp стоит в другом месте или вообще стоит другой набор).

Запускаем браузер и переходим по адресу http://localhost/testlink.

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

Обратите внимание на скриншот. Первое подчеркивание — это как раз проверка версии php из за нее я и отказался от Денвера и перешел на Wamp. Если у вас там зеленым написано OK — то с версией php все в порядке, если же там Failed, то 2 варианта — либо пытаться в ручную обновить версию php у себя в сборке, которую вы используете (я через 3 часа мучений, на это забил, особенно на свежей win 8.1, которая и без того бесит) либо удаляете свой php и ставите wamp (ссылка в первом посте).

Далее идёт проверка настроек php (файл php.ini), там все понятно, ну и т.к. у нас локальный сервер то врядли там будет так сильно перегружена система, по этому можно их вообще не трогать (время сессии, макс время исполнения скрипта и т.п.).

Также для продолжения установки у вас должен стоять один из серверов баз данных (в wamp уже в комплекте идет MySQL сервер и он у вас уже стоит) — в нашем случае — MySQL — OK

И вот 2 последних пункта, если мы устанавливаем на Windows, то заставят нас подправить кое-какие конфиги. Смотрим на скрин и последние 2 строчки подчеркнуты — если у вас так же, что скорее всего так и есть, то делаем следующее:

• Открываем файл C:\wamp\www\testlink\config.inc.php и в нем исправляем пути к папкам logs и upload_area, что бы вышло примерно вот так:

Если все сделали правильно, то возвращаемся на страницу с установкой Testlink, обновляем страницу и видим вот такую картинку:

Продолжаем установку, попадаем на страницу настроек подключения к базе данных и вписываем данные подключения (у нас это был MySQL), следовательно к нему и вписали, жмем Process Setup.

Если все в порядке, то вы увидите вот такое сообщение:

p.s. по умолчанию ваши логин и пароль для входа в систему будут: admin admin

Все, установка завершена! Поздравляю! Будут вопрос — пишите в коменты — помогу.

А у меня не устанавливается! Доходит до подключения к БД и пишет
Writing configuration file: Failed
Дальше пишет, что нужно создать файл config_db.inc.php и прописать туда настройки подключения к бд! Но даже после этого выдает ошибку! Что делать?

Привет! А у меня не поднялся локальный сервер че делать?

TestLink и автоматизированное тестирование - Начинающему тестировщику - Форум тестировщиков

JustNewMaya 26 Дек 2014

Ребят, сразу извините за баян.

Подскажите, пожалуйста, человеку, который занимался тестированием по настоящему никогда. =)

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

Я не могу понять:

1. под автоматизированным тестированием понимается именно "нажатие одной большой кнопки" и прогон всех тест кейсов (периодической прогон тест кейсов)? Поясните.

2. Покрывает ли функциональность TestLink описание тест кейсов, выставление статусов и, главное, автоматизированное тестирование (в моем случае веб сервисов) ?

Petrov.Sergey 26 Дек 2014

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

2) Функциональное тестирование ТестЛинк покрывает. И даже со статусами умеет работать. А вот с интеграцией автоматизированного тестирования у него, кажется, есть проблемы. То есть интеграция есть, но чтобы она заработала, придётся помучиться. Впрочем, гугл выдаёт существование плагина под Jenkins.

Но мне что-то подсказывает, что покрывать автотестами свои сервисы Вы будете через SOAP UI, который не интегрируется в Jenkins, а следовательно, результаты автотестов в ТестЛинк придётся загонять руками.

Почему именно ТестЛинк? Первый попавшийся бесплатный?

JustNewMaya 29 Дек 2014

Сергей, спасибо, что обратили внимание на мой вопрос. Да, честно говоря, так и было - первый попавшийся бесплатный.

Про связку Test link и Jenkins я так же наткнулась в гугле, но решила спросить у профессионалов.

SOAPUI сейчас использую просто для единичных вызовов сервисов.

А вы говорите, что автоматизированное тестирование можно реализовать через SOAP UI?

Да, можно. Правда, я сам этого никогда не делал. SOAP UI использовал только для наглядного представления, что и как в сервисе, а само автотестирование реализовал на чистой JAVA.

Кстати, я ошибся: SOAP UI уже имеет возможность интегрироваться с Maven => может интегрироваться с Jenkins. Последний раз, когда я с ним общался, интеграции с Мавеном не было.

Тут смотрите, как хитро.

SOAP UI уже предоставляет инструмент для автоматизации тестирования. В принципе, богатый, но не обладающий полной свободой. Соответственно, если сервисы реализованы и усложняться не будут, то выгоднее использовать его. Если же будут различные усложнения, то, автоматизируя с помощью SOAP UI, однажды достигнете "предела его возможностей" = всё чаще и чаще будете сталкиваться с проблемой "А как это реализовать?".

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

Однако со временем (год-два) собственный фреймворк будет догонять по нескольким параметрам: объём покрытия, качество тестов. Существует такая временнАя точка Т, после которой собственный фреймворк начнёт по всем фронтам выигрывать у готового инструмента. Но эта точка Т находится далеко за 1 годом тестирования. Не побоюсь предположить, что и за 2 годами.

Какой путь избрать - решать Вам.

Часть из них очень дорогая и является эдаким монстром, умеющим интегрироваться с другими модулями своего производителя (IBM, HP).

Часть из них имеет не сильно дорогую, но ежегодно обновляемую лицензию.

Часть покупается единожды "навсегда".

Часть имеет как платную, так и бесплатную версии.

Часть целиком бесплатные.

Насколько мне известно, большинство на территории бывшего СНГ используют HP QC, Zephyr, JIRA, TestRail, Ситечко, ТестЛинк. Последний используется, по-моему, исключительно в силу своей бесплатности и давления руководства. По крайней мере, других аргументов я не слышал.

JustNewMaya 29 Дек 2014

реализовал на чистой JAVA.

Сергей, что Вы имеете в виду?

У меня есть соблазн написать "потребителей" сервисов, которые начнут вызывать сервисы и анализировать результат. Это похоже на то что Вы делали.

Petrov.Sergey 29 Дек 2014

Сергей, что Вы имеете в виду?

У меня есть соблазн написать "потребителей" сервисов, которые начнут вызывать сервисы и анализировать результат. Это похоже на то что Вы делали.

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

На основе WSDL через утилиту wsimport генерировал JAVA-модель.

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

Потом клепал сами тесты: вызывал генератор запроса, через CXF отправлял запрос и получал ответ. Генерил эталонный ответ. Сравнивал с тем, что пришло.

Генератор запроса использовал статические данные только в параметризованных полях. Остальное рандомизировалось.

Ну, например, тестирование расчёта полиса КАСКО. Марка-модель-модификация машины являются параметром генератора, все остальные данные в запросе = чистый рандом с соблюдением всех логических связок (чтобы водитель, например, не был 1857 года рождения).

Параметров было порядка 5-7 (уже не помню).

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

Параметры нужны исключительно для возможности генерации чётко заданной ситуации. Если необходимости создания чёткой ситуации нет, то все параметры = null или "" (то есть дефолтное значение).

JustNewMaya 29 Дек 2014

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

Сергей, что такое и как должен по Вашему работать генератор эталонного ответа в случае, если сервис возвращает, скажем, только номер договора?

Petrov.Sergey 29 Дек 2014

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

Сергей, что такое и как должен по Вашему работать генератор эталонного ответа в случае, если сервис возвращает, скажем, только номер договора?

1) послал запрос.

2) получил ответ (просто получил, пока ещё не знаю, что в нём. Главное, что не ERROR - на это проверку делаю). Факт получения ответа гарантирует, что сервис уже отработал.

3) полез в БД. По своим посланным данным ищу, что в БД изменилось. Если должен был быть создан договор, то ищу, какой договор был создан по моему запросу. Если не создан => сразу фейл (на этом тест можно завершить, независимо от того, что вернул в ответе сервис). Если создан, беру его номер (от сервиса же ожидается номер договора).

4) на основании данных, взятых из БД, формирую эталонный ответ.

5) сравниваю эталонный ответ с вернувшимся от сервиса (пункт 2). Все поля должны быть идентичны.

Если вернувшийся номер договора не совпадает с моим, который я достал из базы, => фейл.

Таким образом проверяю не только факт возвращения номера договора, но и то, что номер договора вернулся правильный, соответствующий параметрам запроса, а не наобум сгенерённый/выбранный из БД.

Эталонный ответ = объект того же класса, что и ответ сервиса.

Только ответ сервиса = client.getResponse().

А эталонный ответ генерится мной отдельно: Response etalon_resp = new Response();

Генератор эталонного ответа - это метод, принимающий на вход объект "запрос" и возвращающий объект "ответ". Внутренность этого метода = пункты 3+4 из списка в этом посте.

JustNewMaya 30 Дек 2014

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

Petrov.Sergey 30 Дек 2014

А Вы думаете, я руками эти шаги делаю. D

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

Внедрение TestLink

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

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

Ниже вы узнаете о следующем:
1) Что запросить у того человека, который будем устанавливать TestLink.
2) Что желательно настроить (самому или кого-то попросить) после установки TestLink.
3) Как сделать перевод не переведенных элементов UI и использовать его в TestLink.
4) Как перенести тесты из XLS в TestLink.

В этой статье я не рассказал про следующие вещи, которые необходимо или желательно сделать при внедрении TestLink
1) интеграция с bug (issue) tracking системами.
У себя я настроил интеграцию с Redmine именно со стороны TestLink (так как включением всяких плагинов в корпоративный Redmineбыло бы очень рискованно и долго).
2) создание своих шаблонов для отчетов и многом другом интересном и полезном (не делал пока).
3) использование TestLink в рамках бизнес-процессов вашей компании.
4) обучение работе с TestLink.

ВНИМАНИЕ:
Перед редактированием любых файлов конфигурации ТестЛинк необходимо сделать следующее:
1) Открыть файл в режиме редактирования.
2) Изменить режим кодировки файла на UTF-8. Этот шаг необходимо выполнять после КАЖДОГО открытия файла на редактирование!
3) Теперь можно проводить редактирование и сохранять результат.

ТестЛинк взяли последней версии, 9.1.11
Программа бесплатная. Сайт программы: testlink.org/
Для установки надо попросить администратора скачать и установить это ПО. Или установите сами.

1) Номер версии для установки
2) Для работы нужны на сервере БД MySQL и веб-сервер. Часто входят в дистрибутивы ТестЛинк.
3) Необходимо настроить резервное копирование БД. Если вам сделют резервное копирование еще и всех файлов TestLink — отлично. Так безопасней вносить изменения в настройки.
4) Необходимо запросить сделать так чтобы ТестЛинк включили в автозагрузку сервера (чтобы при перезагрузке сервера ТестЛинк сразу начинал работать).
5) Попросить сразу в файле config.inc.php ( он расположен в каталоге /opt/testlink-1.9.11-0/apps/testlink/htdocs программы ТестЛинк )сделать следующие изменения (если нужно нормально поддерживать русский язык):
$tlCfg->default_language = ‘ru_RU’;
$tlCfg->charset = ‘UTF-8’;
При любом редактировании файлов настройки ТестЛинк убедитесь в том что кодируете в UTF-8.

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

Эти шаги делались уже для тонкой настройки, т.е. не сис.админом, а мною, т.е. менеджером.

Для настроек необходимо заходить на сервер ТестЛинк через протокол SSH.
Если у вас стоит Windows, поэтому очень удобно использовать вот эту программу: winscp.net/eng/docs/lang:ru — это популярный Putty с графическим удобным интерфейсом).

Настроить следующие поля в файле config.inc.php ( он расположен в каталоге /opt/testlink-1.9.11-0/apps/testlink/htdocs программы ТестЛинк ):

Показ истории и шагов тестов при прогоне тестов

$tlCfg->exec_cfg->history_on = TRUE;
$tlCfg->exec_cfg->show_history_all_builds = TRUE;
$tlCfg->exec_cfg->show_history_all_platforms = TRUE;
$tlCfg->exec_cfg->steps_exec = true; — начиная с ТестЛинк 1.9.11 это значение стоит по-умолчанию)
$tlCfg->exec_cfg->steps_exec_notes_default = ‘latest’; — это изменение позволяет в заметка каждого шага при новом прогоне теста показывать заметки для этого шага из предыдущего (последнего) прогона теста.

Данные вашей компании в отчетах

часть /* [GENERATED DOCUMENTATION] */:
$tlCfg->document_generator->company_name = ‘название компании’;
$tlCfg->document_generator->company_copyright = date(Y).’ © название компании’;
$tlCfg->document_generator->tc_version_enabled = TRUE;

Настройка авто-коррекции имени теста (при импорте из XML)

При импорте тестов или групп тестов из XML, в случае если такое имя уже есть в системе, TestLink сформирует новое имя на основе существующего.
//$tlCfg->testcase_cfg->duplicated_name_algorithm->type = ‘stringPrefix’;
//$tlCfg->testcase_cfg->duplicated_name_algorithm->text = strftime("%Y%m%d-%H:%M:%S", time());
$tlCfg->testcase_cfg->duplicated_name_algorithm->type = ‘counterSuffix’;
$tlCfg->testcase_cfg->duplicated_name_algorithm->text = " (%s)";

Лого вашей компании

Файлы ТестЛинка с графикой храняться тут: /opt/testlink-1.9.11-0/apps/testlink/htdocs/gui/themes/default/images.
Вставляем в каталог с изображениями два файла с такими же параметрами как файлы tl-logo-transparent-25.png и tl-logo-transparent-12.5.png
Редактируем в файле config.inc.php ( он расположен в каталоге /opt/testlink-1.9.11-0/apps/testlink/htdocs программы ТестЛинк )следующие поля:
$tlCfg->logo_login = ‘файл с вашим лого.png’; — размер файла 231*56 пикселей, transparent
$tlCfg->logo_navbar = ‘файл с вашим лого.png’; — размер файла 116*28 пикселей, transparent

Перевод некоторых частей UI

В файле config.inc.php можно сделать перевод для текста, используемого в описании тестов, создающихся автоматически для требований.
Нужно сделать перевод для текста, предоставляемого этими полями:
$tlCfg->req_cfg->testcase_summary_prefix
$tlCfg->req_cfg->testcase_summary_prefix_with_title_and_version

В самом TestLink можно редактировать роли, т.е. создавать новые и менять возможности, предоставляемые для каждой из ролей.
Вообще, настройка ролей достойна отдельной статьи.
Но, например, проследите чтобы была включена для практически всех ролей опция Show Test Cases Assigned to me.

В поставку ТестЛинк входит локализация на русский язык.
Проблема в том, что примерно 40% элементов пользовательского интерфейса там не переведены на русский язык или для которых хотелось бы перевод поменять.
Поэтому можно выполнить дополнительную работу по переводу. К сожалению, не все элементы интерфейса запрограммированы так, чтобы перевод для них был в одном файле.
Поэтому, даже после полного перевода текста из файла custom_strings.txt останутся элементы, не переведенные на русский язык.

Что нужно сделать чтобы перевести на русский (и любой другой) язык части UI:
1) Перейти в каталог /opt/testlink-1.9.11-0/apps/testlink/htdocs/locale/ru_RU (если у нас используется русский язык для UI) на сервере с ТестЛинк
2) Скопировать к себе на ПК файлы custom_strings.txt.example и strings.txt
3) Скопировать из strings.txt в custom_strings.txt.example данные
4) Сделать нужный перевод в файле custom_strings.txt.example — ВНИМАНИЕ. ПЕРЕД НАЧАЛОМ РЕДАКТИРОВАНИЯ НУЖНО СДЕЛАТЬ ПРОВЕРКУ, ПРИВЕДЕННУЮ СРАЗУ ПОСЛЕ ЭТОЙ ПОСЛЕДОВАТЕЛЬНОСТИ ШАГОВ!
5) Переименовать custom_strings.txt.example в custom_strings.txt
6) Скопировать файл custom_strings.txt в каталог /opt/testlink-1.9.11-0/apps/testlink/htdocs/locale/ru_RU на сервере с ТестЛинк

Перед редактированием любых файлов конфигурации ТестЛинк необходимо сделать следующее:
1) Открыть файл в режиме редактирования.
2) Изменить режим кодировки файла на UTF-8. Этот шаг необходимо выполнять после КАЖДОГО открытия файла на редактирование!
3) Теперь можно проводить редактирование и сохранять результат.

Новые версии Excel плохо поддерживают (никак!) тот формат XML, который понимает ТестЛинк.
Поэтому для портирования используется внешнее ПО, распространяемое бесплатно.
Программа называется EX-converter.
Это свободное ПО. Вот его страничка: sourceforge.net/projects/ex-converter/
Программа работает под MS Windows.

Зайдите в TestLink. Слева внизу будет элемент Documentation. Выбирайте нужные документы и читайте (на английском). Там есть, среди прочего, руководство пользователя и руководство по настройке TestLink.