Testlink. Отчеты

      В разделе «Отчеты» в Testlink можно посмотреть различные отчеты по тестам, прогонам и обнаруженным багам. Отчеты строятся для каждого конкретного тест-плана отдельно. Можно выбрать удобный формат вывода отчета (html, excel, word).
      Несмотря на то, что Testlink предлагает более 10 различных отчетов, полезными и используемыми для меня стали только два:

• Отчет о прогоне тестов – отображает выполнение тестов по версиям проверяемого приложения

•  Отчет об обнаруженных багах – показывает все баги для всех версий, найденные для тест-плана и указанные в Testlink. Баги выводятся с указанием теста, к которому они относятся. Для багов показываются статусы «Открыт», «Закрыт».

                                              
       Другие статьи о Testlink:

•  Управление списком тестов
• Порядок создания теста
• Порядок действий для прогона тестов  
• Связь с багтрекером
• Дополнительные возможности

Testlink. Порядок действий для прогона тестов

      Краткое описание процесса прогона тестов для нашего проекта:
      1. Создать необходимые тесты в разделе «Тесты»

      2. На главной странице Testlink перейти по ссылке «Редактировать версию (сборку)» (находится в разделе «Планы тестирования»). Добавить версию для тестирования, в разделе «Описание» указать, какие изменения были сделаны в данной версии. Указать дату тестирования. Выставить флаги «Активна» и «Открыта»

      3. На главной странице Testlink перейти по ссылке «Добавить/удалить тесты» (находится в разделе «Наборы тестов»). Выбрать тест-план и добавить в него новые тесты, созданные в п.1

      4. Перейти в раздел «Прогон», выбрать тест-план, выбрать сборку (версию). Для выполнения теста нужно выбрать его в списке. В списке серым цветом выделяются не пройденные тесты, зеленым – пройденные без ошибок, красным – пройденные с ошибками. После выполнения каждого теста нужно сохранить результат прогона. Если найдены ошибки, то выбираем «Добавить баг» и указываем номер бага из трекера.


                                              
       Другие статьи о Testlink:

•  Управление списком тестов
• Порядок создания теста
• Отчеты 
• Связь с багтрекером
• Дополнительные возможности

Testlink. Порядок создания теста

      В своей работе я использую следующий порядок при создании теста в Testlink:
      1. В списке тестов выбрать папку, в которой будет находиться тест. Нажать на кнопку «Создать тест»

      2. Заполнить форму создания теста:

• Указать название теста. Название должно быть уникальным.
• В разделе «Описание теста» указать дополнительную информацию для теста (архив, логин/пароль для проверки, ссылки и т.п.).
• Указать важность теста.
• Выбрать ключевые слова для теста из списка.
• Если планируется создать несколько тестов подряд, то нужно выставить флаг «check to create another test case after saving». Если флаг не выставлен, то после создания будет переход к содержимому теста.
• Нажать на кнопку «Создать»

      3. Перейти к тесту. Создать шаги теста. Тест в Testlink выглядит в виде таблицы со столбцами

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

 


                                              
       Другие статьи о Testlink:

•  Управление списком тестов
• Порядок действий для прогона тестов  
• Отчеты 
• Связь с багтрекером
• Дополнительные возможности

 

TestLink. Управление списком тестов

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

      Скачать версию TestLink можно с сайта http://www.teamst.org/. Там же находится необходимая документация по установке.

      Очень хорошее описание процесса установки можно посмотреть тут

      TestLink может использоваться для хранения тестов сразу к нескольким программным продуктам, что очень удобно. Для просмотра и создания тестов нужно перейти по ссылке «Тесты» из меню Testlink. Список тестов имеет иерархическую структуру. В нашем случае проект делится на модули, модули делятся на подразделы, подразделы содержат разнообразные тесты. Менять порядок в списке тестов можно с помощью перетаскивания тестов (drug-n-drop).

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

      В нашем проекте для тестов используются следующие ключевые слова:

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

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


                                              
       Другие статьи о Testlink:

• Порядок создания теста
• Порядок действий для прогона тестов  
• Отчеты 
• Связь с багтрекером
• Дополнительные возможности

Экономическая выгода от автоматизации тестирования

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

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

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

      2. Необходимо разбить функциональность системы на небольшие функциональные модули. Разбиение должно быть как можно более детальным – чем меньше подмодули, тем оптимальнее будет оценено покрытие автотестами.

      3. Для каждого из модулей оценивается время как на ручное тестирование, так и на автоматизированное:

            Tdev - время, необходимое для разработки автоматического теста.
            Tman – время, затрачиваемое на ручное тестирование.
            Tref – среднее время, необходимое для изменения автоматического скрипта после изменения функциональности.
            Tref_manual - среднее время, необходимое для изменения автоматического скрипта после изменения функциональности
            nregression - относительное количество тестов, прогоняемых без изменений
            Ntotal – общее количество итераций тестирования функционала за предполагаемое время жизни функционала (системы).
      Тогда для расчета общего количества времени, затрачиваемого на ручное и автоматическое прохождение тестов на всех итерациях жизненного цикла системы, могут быть применены формулы:

            Tmanual_total = Ntotal * Tman + Ntotal * (1-nregression)* Tref_manual  

            Tautomated_total = Tdev + Ntotal *(1- nregression )* Tref

      Автоматизация будет выгодной (при использовании бесплатных инструментов тестирования) при выполнении условия

            Tmanual_total ≤ Tautomated_total

      Для расчёта выгоды автоматизированного тестирования с использованием коммерческих инструментов тестирования, необходимо рассчитать стоимость ручного и автоматизированного тестирования:
           ∑(Tmanual_total ) – сумма трудозатрат на ручное тестирование частей функционала, которые предполагается тестировать автоматически.
            ∑(Tmanual_total ) – сумма трудозатрат на автоматическое тестирование частей функционала, которые предполагается тестировать автоматически.
            St – себестоимость тестировщика.
            Stesting_tool – себестоимость инструмента тестирования
            Npart – удельный вес трудозатрат на тестируемый продукт среди продуктов, которые тестируются соотвествующим коммерческим инструментом тестирования.
      Расчет стоимости ручного и автоматизированного тестирования производится по формулам:

            Cmanual = ∑(Tmanual_total ) * St

            Cautomated = ∑(Tautomated_total ) * St + Stesting_tool*Npart

      Критерий выгоды автоматизации при использовании коммерческих инструментов тестирования:
            Сmanual ≤ Сautomated

      4. При определении необходимости автоматизации тестирования дополнительно могут учитываться следующие факторы:

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

Недостатки автоматизации тестирования

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

1. Может быть неправильно оценён масштаб возможного покрытия системы автоматическими тестами, например, при попытке автоматизации того, что не должно быть автоматизировано. В таком случае процесс автоматизации становится неоправданно долгим и дорогим.
2. Очевидно, что наибольший эффект можно получить при автоматизации регрессионного тестирования, однако именно этот вид автоматизации имеет наибольшее количество минусов. Регрессионное тестирование используется для проверки новых версий, часто содержащих в себе большое количество дополнений и исправлений по сравнению с предыдущими версиями. При изменении в программе, тест уже не понимает, где произошло улучшение, дополнение, нововведение, а где ошибка. Поэтому всегда необходимо проверять актуальность используемого автоматического теста. 
3. При автоматизации регрессионного тестирования может случиться так, что вследствие изменений функциональности разработанный тест не может быть использован в дальнейшем. Поэтому прежде чем заниматься автоматизацией, необходимо четко представлять план дальнейшего развития проверяемого программного продукта, чтобы избегать подобных ситуаций. 
4. Еще одним недостатком автоматизации тестирования может стать отсутствие необходимой квалификации у сотрудников. Этот факт приводит к значительному увеличению времени при автоматизации и в дальнейшем при использовании автоматических тестов. Оператор теста должен обладать соответствующими знаниями: как использовать тест, как его конфигурировать, как его анализировать. Если оператора сменить, то результат автоматизации получится совсем другой.
5. Следствием из предыдущего пункта может стать наличие ошибок в тестовом скрипте. Например, если ошибка неверно определяется в автоматическом тесте, тогда она влечет за собой другие «ошибки», которые на самом деле ошибками не являются. Это может внести значительную сумятицу в процесс тестирования.
6. Также не стоит забывать про экономическую эффективность автоматизации. Возможна ситуация, что стоимость лицензий на инструменты для автоматизации превысят экономическую выгоду от использования автоматизированного тестирования в проектах. Кроме того, необходимо учитывать, что использование инструментов автоматизации может потребовать дополнительных расходов на необходимое оборудование: для их установки зачастую требуются отдельные сервера, и, возможно, потребуется их покупка.

Преимущества автоматизации тестирования

      Говоря о преимуществах автоматизации тестирования, чаще всего упоминают сокращение времени, затрачиваемого на проверку разработанного программного продукта. Однако существует и много других преимуществ:

1. Снижение стоимости итерации тестирования.
2. Увеличение скорости тестирования без ущерба для результата.
3. Повышение надежности систем за счет улучшения качества тестирования.
4. Обеспечение возможности многократного использования разработанных тестовых сценариев без увеличения стоимости тестирования.
5. Обеспечение прозрачности информации о качестве принимаемых изменений к программному обеспечению.
6. Усиление контроля процесса обеспечения качества.
7. Прозрачность и простота планирования времени для проведения тестирования программного обеспечения.
8. Автоматическое формирование отчётов о тестировании.
9. Рациональное использование рабочего времени команды тестирования: один тестировщик может параллельно осуществлять тестирование нескольких систем, автоматические тесты могут выполняться в нерабочее время (ночь, выходные).
10. Использование передовых технологий в сфере обеспечения качества.
11. Сокращение времени на проведение тестирования программного обеспечения.
12. Набор тестов ограничивается в первую очередь производительностью системы, а не доступным резервом времени тестировщиков.
13. Минимизация влияния человеческого фактора на процесс тестирования.
14. Нельзя упускать и психологический аспект автоматизированного тестирования. Не секрет, что во многих компания инженеры-тестировщики ставятся ниже разработчиков, как по престижу, так и по зарплате. С точки зрения построения эффективных проектных команд это совершенно неправильно, так как тестировщики, вместо того, чтобы развиваться в профессиональном плане, стремятся переквалифицироваться в разработчики. Такие тестировщики обычно слабо мотивированы на качественное ручное тестирование. Участие в создании автоматических тестов даёт таким сотрудникам ощущение повышения престижности в команде, профессиональный рост, повышает заинтересованность и мотивацию в обеспечении качества проектов. Тестировщик перестает восприниматься «глупее» программиста, ведь разработчик автотестов по сути тоже программист.

Недостатки автоматизации тестирования

Получение IP-адреса по имени хоста в PowerShell

Чтобы узнать IP-адрес по имени хоста нужно в PowerShell выполнить команду:
[System.Net.Dns]::GetHostAddresses("yandex.ru")


Если нужно наоборот узнать имя хоста по IP-адресу:
[System.Net.Dns]::GetHostbyAddress("87.250.250.11")


Если же нужно получить IP-адрес в виде строки для дальнейшего использования в коде powershell-скрипта, то нужно использовать следующую команду:
[System.Net.Dns]::GetHostaddresses("yandex.ru")[0].ipaddresstostring


Для получения IP-адреса рабочего компьютера:
[System.Net.Dns]::GetHostaddresses($env:COMPUTERNAME.split('.')[0])[0].ipaddresstostring