Файл: Федеральное государственное автономное образовательное учреждение высшего образования казанский (приволжский) федеральный университет высшая школа информационных технологий и информационных систем.docx

3. 1   ...   15   16   17   18   19   20   21   22   ...   31

---

Метрики для оценки стоимости тестирования

1. Оценка рентабельности инструментария для автоматизированного тестирования

Для того, чтобы избежать дорогостоящих изменений в автоматизации тестирования в дальнейшем, важно оценить организационные потребности, прежде чем инвестировать большие суммы в автоматизированные средства тестирования. Организационные потребности включают в себя подтверждение того, что выбранный инструмент работает должным образом с выбранными технологиями, вписывается в бюджет организации и временные рамки для ввода инструмента [7]¹¹⁴.

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

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

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

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

Согласно [25]¹¹⁵, критерии оценки для оценки инструмента тестирования включает в себя простоту использования, мощность, надежность, функциональность, простоту введения, качество поддержки, стоимость инструмента и согласуется с организационной политикой и целями.

---

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

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

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

Для того, чтобы убедиться, что автоматизированное средство отвечает потребностям организации и совместимо с различными технологиями, лучше проверить инструмент на прототипе приложения [7]¹¹⁶. Прототип должен состоять из функций и технологий, которые будут использоваться в организации. Общей проблемой для автоматизированных средств тестирования является его неспособность распознавать элементы управления третьей стороны. Эти проблемы несовместимости будут определены ранее, если проектная группа будет оценивать инструмент с самого начала.

Резюме дискуссии об экономической эффективности автоматизированного инструмента обозначено в таблице 28.

Таблица 24. Показатель "Оценка рентабельности инструментария для автоматизированного тестирования"

Свойство показателя	Показатель
Цель	Оценить преимущества инструмента автоматизации по отношению к его цене
Польза показателя	Помогает избежать последующих изменений в автоматизации тестирования
	Помогает выбрать самый подходящий организации инструмент
Оценка инструмента	Оценка показателя должна включать следующие элементы: Совместимость с ОС, БД, ЯП Оценка к требованиям производительности приложения Потребность в нескольких инструментах Поддержка для верификации данных Стоимость обучения Типы тестов для автоматизации Простота в использовании Мощность Надежность Функциональность Простота внедрения Качество поддержки Стоимость инструмента Соответствие политике и целям организации

---

4. 1   ...   16   17   18   19   20   21   22   23   ...   31

---

Метрики для оценки объема тестирования

К категории «Объем» относятся следующие показатели:

• 
  оценка Тест-кейсов;
  
• 
  число регрессионных тестов;
  
• 
  тесты для автоматизации.
  

1. Оценка Тест-кейсов

Показатель оценки Тест-кейсов будет рассмотрена в сочетании с показателем «Техники тестирования» этапа тест-дизайна.

2. Число регрессионных тестов

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

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

Незапланированное заранее регрессионное тестирование, выполняющееся вручную, делает использование ресурсов неэффективным [7]¹¹⁷.

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

Существуют различные эмпирические исследования, которые устанавливают актуальность выбора регрессии [49]¹¹⁸.

Согласно [21]¹¹⁹, есть некоторые рекомендации, которым необходимо следовать при выборе тестов для регрессионного тестирования. Эти принципы используют меры сложности программы (например, цикломатическую сложность и метрики Холстеда), чтобы определить модули, сложность которых выходит за пределы базовой сложности в компании. Эти модули трудно проверить, согласно [49], поэтому они являются кандидатами для регрессионного тестирования. Другие принципы рекомендуют использовать опыт предыдущих разработок для выбора тестов.

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

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

Согласно [7], регрессия должна включать в себя тестовые случаи, которые проверяют функциональность с повышенным риском и наиболее частые пути выполнения программы. После прохождения этой стадии нужно более детально рассматривать другие области.

---