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

2. 
   Затраты на обучение и оснащение
   

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

3. 
   Метрики для оценки качества тестирования
   

Следующие показатели этапа планирования тестирования относятся к категории «Качество»:

• 
  тестовое покрытие;
  
• 
  эффективность дымового тестирования;
  
• 
  качество тестового плана;
  
• 
  достижение поставленных целей.
  

1. 
   Измерение тестового покрытия
   

Тестовое покрытие будет рассмотрено с комбинации с полнотой тестов на этапе тест-дизайна.

2. 
   Измерение эффективности дымового тестирования
   

Дымовые тесты (смоук-тесты) формируют группу тестов, которые определяют первичную стабильность системы, то есть проверяют, что система функционирует в нормальных условиях [4]⁸⁵. Основная цель этих тестов не обнаружить ошибки, а дать команде тестирования основания для начала тестирования всей системы. Для дымовых тестов существуют некоторые хорошие принципы:

• 
  дымовые тесты нацелены на широкий охват, а не на проверку в глубину, то есть на функционал верхнего уровня приложения;
  
• 
  смоук-тесты проверяют систему от начала и до конца, что позволяет обнаружить критичные большие ошибки [36]⁸⁶;
  
• 
  тесты, включенные в дымовое тестирование, охватывают основные операции, которые являются наиболее часто используемыми, например, вход в систему, добавление и удаление записей;
  
• 
  дымовое тестирование должно быть подмножеством набора для регрессионного тестирования. Такие тесты выполняются каждый раз при получении новой сборки, чтобы убедиться, что основная функциональность работает;
  
• 
  дымовые тесты увеличивается в размерах и покрытии в процессе расширения системы [36];
  
• 
  смоук-тесты должны быть автоматизированы в первую очередь, потому что они будут работают большую часть времени;
  
• 
  тесты должны быть запущены в тестовой среде системы;
  
• 
  успешное прохождение смоук-тестов дает разрешение на дальнейшее тестирование системы после прохождения модульного тестирования и тестирования интеграции;
  
• 
  другие примеры смоук-тестов:
  

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

---

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

Дымовое тестирование является важной частью процесса сборки программного обеспечения.

Последовательность сборки программного обеспечения выглядит следующим образом [7]⁸⁸:

1. Компиляция сборки;

2. Юнит-тестирование;

3. Дымовое тестирование;

4. Регрессионное тестирование.

Итог дискуссии об измерении дымовых тестов приведен в таблице 14.

Таблица 11. Показатель "Измерение эффективности дымового тестирования"

Свойство показателя	Показатель
Цель	Установить стабильность приложения для продолжения тестирования
Польза показателя	Устанавливает стабильность системы и сборок
	Устанавливает критерий для начала тестирования системы
Как правильно использовать	Смоук-тесты должны иметь широкий охват
	Смоук-тесты должны проверять систему от начала и до конца
	Тесты, включенные в дымовое тестирование, должны охватывать основные операции, которые являются наиболее часто используемыми
	Тесты нужно автоматизировать и сделать частью регрессии
	Нужно разрабатывать тесты в сотрудничестве с разработчиками
	Проверка кода помогает определить критические области для смоук-тестирования

3. 
   Измерение качества тестового плана
   

Есть ряд стандартов для документирования плана тестирования, но они имеют некоторые различия. План тестирования может быть оценен только с точки зрения возложенных на него ожиданий или тех функций, для которых он будет служить [37]⁸⁹. Качество плана тестирования также зависит от ситуативных факторов и обстоятельств. Согласно оценке модели плана тестирования, представленного [37], плана тестирования должен обладать показателями качества, как описано в таблице 15.

Таблица 12. Показатели качества плана тестирования

Показатель качества	Описание
Полезность	Будет ли выполнять тест-план свои основные функции?
Точность	Точны ли утверждения тест-плана?
Эффективность	Эффективно ли будут использоваться ресурсы?
Адаптивность	Будет ли он адаптивен к изменениям в проекте?
Ясность	Является ли план согласованным и однозначным?
Удобство	Является ли тест-план простым в сопровождении и хорошо организованным?
Соответствие	Соответствует ли он представленным требованиям?
Основательность	Является ли он результатом эффективной работы по планированию тестирования?
Осуществимость	Имеет ли организация возможности для его осуществления?

---

Чтобы оценить качество показателей тест-плана, [37]⁹⁰ предлагает эвристический подход, то есть принятые практические правила, отражающие опыт и исследования.

Бергер описывает многомерный качественный метод оценки планов тестирования с использованием разделения на подразделы. Согласно [38]⁹¹ существует 10 подразделов, которые составляют деятельность по планированию тестирования:

1. 
   Цель;
   
2. 
   Область применения;
   
3. 
   Покрытие;
   
4. 
   Риски;
   
5. 
   Данные;
   
6. 
   Оригинальность;
   
7. 
   Коммуникация;
   
8. 
   Полезность;
   
9. 
   Полнота;
   
10. 
    Дальновидность.
    

Результат обсуждения качества тест-плана представлен в таблице 16:

Таблица 13. Показатель "Измерение качества тестового плана"

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

4. 
   Измерение оценки области для дальнейшего тестирования и ожидаемые дефекты
   

К данной категории относятся следующие показатели:

• 
  количество ошибок на этапе документации;
  
• 
  ожидаемое количество ошибок;
  
• 
  классификация ошибок.
  

1. 
   Количество ошибок на этапе документации и ожидаемое количество ошибок
   

Данные показатели будут рассмотрены в комплексе с показателем «Определение области для дальнейшего тестирования» на этапе тест-дизайна.

2. 
   Классификация ошибок
   

Существуют разные способы классификации ошибок, найденных в процессе тестирования системы. Один из видов классификации предложенный [25]⁹² представлен в таблице 17 (см. Приложение 4).

---

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

Кроме классификации ошибок существуют также уровни влияния ошибок на систему. В таблице 18 представлены 5 уровней:

Таблица 14. Уровни влияния ошибок на систему

Уровень	Описание
Катастрофический	Критичная потеря данных, критичная недоступность системы, критичные проблемы с безопасностью
Опасный	Дефекты, вызывающие серьезные последствия для системы
Серьезный	Ошибки, которые должны быть исправлены, есть обходной путь
Незначительный	Ошибки, имеющие незначительные последствия
Неопасный	Тривиальные ошибки

Существует и другое определение уровней влияния:

Уровень 0.

Этот уровень содержит ошибки, из-за которых происходят:

• 
  сбой системы;
  
• 
  невосстанавливаемая потеря данных;
  
• 
  отсутствие альтернативных путей;
  
• 
  потеря основной функциональности;
  
• 
  потеря данных.
  

Уровень 1.

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

Уровень 2.

• 
  Ошибки, связанные с интерфейсом;
  
• 
  грамматические ошибки.
  

В результате обсуждения показателя «Классификация ошибок» этапа планирования получаем следующую таблицу 19:

Таблица 15. Показатель "Классификация ошибок"

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

---

5. 1   ...   11   12   13   14   15   16   17   18   ...   31

---